Re: Bug in pg_describe_object - Mailing list pgsql-hackers

From Joel Jacobson
Subject Re: Bug in pg_describe_object
Date
Msg-id AANLkTinQwNtrJ7kcEp7htZvdz06O2ZzBLWwjqzYmBbYY@mail.gmail.com
Whole thread Raw
In response to Re: Bug in pg_describe_object  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Bug in pg_describe_object  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
2011/1/11 Tom Lane <tgl@sss.pgh.pa.us>:
> It would make dependency error messages significantly longer and less
> readable.  Quite aside from the point at hand here, we elide schema
> names in many cases (and it looks like there are some code paths where
> getObjectDescription never bothers to print them at all).  Another issue
> that might make it interesting to try to use the output for purposes
> other than human-readable descriptions is that we localize all the
> phrases involved.
>
> My point is that this isn't a bug fix, it's more like moving the
> goalposts on what getObjectDescription is supposed to do.  And I'm not
> even very sure where they're being moved to.  I haven't seen a
> specification for an intended use of pg_describe_object for which its
> existing behavior would be unsatisfactory.

Thanks for some good arguments. I now agree with you it would be a bit
counter productive to change the existing pg_describe_object.
Due to the localization of the phrases and the lack of mandatory
namespace inclusion, you lose the comparison ability anyway.

I instead propose we introduce a new function named
pg_get_object_unique_identifier( classid oid, objid oid, objsubid
integer ) returns text.

The name would make sense since we already have a
pg_get_function_identity_arguments( func_oid ), for a similar purpose
but solely for functions.

--
Best regards,

Joel Jacobson
Glue Finance


pgsql-hackers by date:

Previous
From: Maciej Sakrejda
Date:
Subject: casts: max double precision > text > double precision fails with out or range error
Next
From: Magnus Hagander
Date:
Subject: Re: Streaming base backups