I have a large table (audit) in which I store relation ID of the schema and table. This is conveniently populated by trigger using TG_RELID. It is also convenient because I can index it and the index would be smaller than if I were to store "schema"(text) and "table"(text) columns separately and index them. Also, I can then do queries using WHERE relation_id = 'myschema:mytable'::regclass and it just works.

My question is if this is "safe" to do in terms of backup/restore (will the schema.table have the same regclass/oid in target server and it did in the source server?

Any other issue I should be aware of?

2 Answers 2


I wouldn't rely on the specific values of OIDs to be portable at all. Even if you try it and you find it to work with the current version of PostgreSQL, it might not do so in newer releases.

If you backup your database in a source machine and try to restore it on a different machine (or, in general, another PostgreSQL Database Cluster) that does already have other databases, schemas, etc. it is very likely that the different OIDs your source database was using are already used to represent other different things in the target database.

The schema_name.table_name correspondence to an OID is handled by PostgreSQL within its system tables. If you need equivalent functionality, with the guarantee it behaves the way you need it to and not the way PostgreSQL uses its internal OIDs, I'd recommend you actually duplicate this behaviour with a your_tables table, where you store an arbitrary id (a serial) and schema_name, table_name. This way, your database is safe to backup and restore, and you're likely to avoid modifications for any newer postgreSQL version.

You may need an extra lookup in your trigger(s), but might save you a lot of trouble in the future.


The contrib module pg_stat_statements uses OIDs to fingerprint queries. So, the stability guarantees you'll get by doing this yourself are essentially the same as the documented guarantees for that module.

It sounds like you're talking about stability when using pg_dump. There is no guarantees around stability there. Only for physical backups.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.