Make audit id column type configurable

[nextstopsun]

@FxKu Can you please share your thoughts on what it takes to make it possible?
I'd like to use my existing UUID columns as audit keys.

[FxKu]

Sorry to keep you hanging here for so long. With the last release I tried to set the ground for further customization, e.g. having the audit_schema_log table for global configuration and use audit_table_log for local config. For example, now we have audit_id_column which in theory should allow to specify existing columns there. So far, it's forbidden but I plan to make it possible - and I hope for integer based keys it should not be too hard.

Different data types are another story though as all audit_id columns are implicitly referenced by the row_log's audit_id column.
Plus, it affects great parts of the source code like restoring, reverting etc. Don't know if I can change funstions and sprocs to take up anyelement for audit_id arguments. If somebody starts auditing with another data type a new column could be added to the row_log, like audit_id_uuid etc. (or maybe even a whole new table). You see, many open questions left.

Feel free to also make suggestions if you had ideas how to tackle this.

So maybe, on first init you either specify the data type and thus all other tables in the database will be restricted to use that data type for tracing.

[nextstopsun]

I think you don't have to make it anyelement in the first place. Setting row_log id column type once should restrict all audited tables to use this type. So column type can be set once globally and be sufficient for most cases.

On the other hand, if anyone wants to audit with both integer and some other columns at the same time, another audit schema can be added to DB and audit triggers can call functions from that schema.
This approach can add complexities (e.g. with logging DDL), but is quite an extreme case.