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 <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
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