On Jan11, 2011, at 16:12 , Tom Lane wrote:
> Joel Jacobson <joel@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