Re: Bug in pg_describe_object

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