On Jan11, 2011, at 16:12 , Tom Lane wrote: > Joel Jacobson <j...@gluefinance.com> writes: >> I instead propose we introduce a new function named >> pg_get_object_unique_identifier( classid oid, objid oid, objsubid >> integer ) returns text. > > Seems like concatenating the OIDs would accomplish that. (If you > think not, well, you still haven't explained what problem you're trying > to solve...)
I think the OP wants a unique identifier which changes neither on dump & reload nor on major version upgrades. I can see the value in that if you e.g. want to compare the structures of two different postgres databases. It seems impossible to guarantee the identifier to not change between major versions, though - if the structure of that catalog change, so will the identifier. @OP: Wouldn't it be sufficient to provide such a thing for structure objects that people are actually going to modify on a regular basis? I suggest restricting this to tables (including SQL/MED foreign tables) views sequences types servers (SQL/MED) tsearch configurations tsearch dictionaries for which <schema>.<name> suffices, triggers constraints columns for which <schema>.<table>.<name> should work, and functions operators which need to include the argument types. The reg* types already solve this for tables, views, sequences (regclass) tsearch configurations (regconfig) tsearch dictionaries (regdictionary) types (regtype) functions (regprocedure) operators (regoperator) which leaves servers triggers constraints columns best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
