Re: refactoring comment.c

Excerpts from KaiGai Kohei's message of lun ago 16 00:19:54 -0400 2010:
> (2010/08/16 11:50), Robert Haas wrote:

> When we were developing largeobject access controls, Tom Lane commented
> as follows:
> 
> * Re: [HACKERS] [PATCH] Largeobject access controls
>   http://marc.info/?l=pgsql-hackers&m=125548822906571&w=2
> | I notice that the patch decides to change the pg_description classoid for
> | LO comments from pg_largeobject's OID to pg_largeobject_metadata's.  This
> | will break existing clients that look at pg_description (eg, pg_dump and
> | psql, plus any other clients that have any intelligence about comments,
> | for instance it probably breaks pgAdmin).  And there's just not a lot of
> | return that I can see.  I agree that using pg_largeobject_metadata would
> | be more consistent given the new catalog layout, but I'm inclined to think
> | we should stick to the old convention on compatibility grounds.  Given
> | that choice, for consistency we'd better also use pg_largeobject's OID not
> | pg_largeobject_metadata's in pg_shdepend entries for LOs.
> 
> He concerned about existing applications which have knowledge about internal
> layout of system catalogs, then I fixed up the patch according to the suggestion.

I think that with this patch we have the return for the change that we
didn't have previously.  A patch that changes it should also fix pg_dump
and psql at the same time, but IMHO it doesn't make sense to keep adding
grotty hacks on top of it.

Maybe we could do with a grotty hack in obj_description() instead?
(...checks...) 
Oh, it's defined as a SQL function directly in pg_proc.h :-(

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support