Обсуждение: pgsql-server: Minor catalog cleanups for composite-type stuff.

Log Message:
-----------
Minor catalog cleanups for composite-type stuff.  Adjust signatures shown
in pg_proc for record_in, record_out, etc to reflect that these routines
now make use of the second OID parameter.  Remove the ancient SET entry
in pg_type, which is now highly unlikely to ever become used again.
Adjust type_sanity regression test to match.

Modified Files:
--------------
    pgsql-server/src/include/catalog:
        catversion.h (r1.233 -> r1.234)

(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/catalog/catversion.h.diff?r1=1.233&r2=1.234)
        pg_proc.h (r1.334 -> r1.335)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/catalog/pg_proc.h.diff?r1=1.334&r2=1.335)
        pg_type.h (r1.152 -> r1.153)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/catalog/pg_type.h.diff?r1=1.152&r2=1.153)
    pgsql-server/src/test/regress/expected:
        type_sanity.out (r1.21 -> r1.22)

(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/test/regress/expected/type_sanity.out.diff?r1=1.21&r2=1.22)
    pgsql-server/src/test/regress/sql:
        type_sanity.sql (r1.21 -> r1.22)

(http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/test/regress/sql/type_sanity.sql.diff?r1=1.21&r2=1.22)

> Minor catalog cleanups for composite-type stuff.  Adjust signatures shown
> in pg_proc for record_in, record_out, etc to reflect that these routines
> now make use of the second OID parameter.  Remove the ancient SET entry
> in pg_type, which is now highly unlikely to ever become used again.
> Adjust type_sanity regression test to match.

Hehe - speaking of how we never remove types :)

Chris

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
>> ...  Remove the ancient SET entry
>> in pg_type, which is now highly unlikely to ever become used again.

> Hehe - speaking of how we never remove types :)

Hm?  I think the recent discussion was about contracting not to
arbitrarily reassign OIDs for existing types.  Nobody said anything
about not being able to remove types, especially not ones as dead as
this doornail was.

            regards, tom lane

> Hm?  I think the recent discussion was about contracting not to
> arbitrarily reassign OIDs for existing types.  Nobody said anything
> about not being able to remove types, especially not ones as dead as
> this doornail was.

Yep, that's fine.  I believe someone said that we'd never removed one
before, but now we should be careful not to reuse the SET type OID?

Chris

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> Yep, that's fine.  I believe someone said that we'd never removed one
> before, but now we should be careful not to reuse the SET type OID?

Uh, why worry?  If you had an application that depended in any way
shape or form on the SET type, then I already broke it ...

            regards, tom lane

> Uh, why worry?  If you had an application that depended in any way
> shape or form on the SET type, then I already broke it ...

Wasn't it a pg_upgrade consideration or something?

Chris

Christopher Kings-Lynne wrote:
> > Uh, why worry?  If you had an application that depended in any way
> > shape or form on the SET type, then I already broke it ...
>
> Wasn't it a pg_upgrade consideration or something?

No.  The issue was having applications hard-code type oids for
performance reasons.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
>> Uh, why worry?  If you had an application that depended in any way
>> shape or form on the SET type, then I already broke it ...

> Wasn't it a pg_upgrade consideration or something?

No, I thought the discussion was about whether client code could get
away with hard-coding OID values for popular types.  ISTM it's
sufficient to promise that a type's OID won't change while the type
exists.  If we remove a type that your client depends on, you've got
worse problems than what the OID is.

            regards, tom lane