Why is pg_lsn marking itself a preferred type?
One of these doesn't belong:
postgres=# select typname, typcategory from pg_type where typispreferred;
typname | typcategory
-------------+-------------
bool | B
text | S
oid | N
float8 | N
inet | I
timestamptz | D
interval | T
varbit | V
pg_lsn | U
(9 rows)
Was there any actual rationale to this, or was it just somebody who did
not understand what that bit is for?
I think it's probably mostly harmless given the lack of casts to or from
pg_lsn, but it's still a darn bad idea to have any preferred types in the
'U' category. If we leave it like this it will bite us in the rear
eventually.
The most expedient response at this late date seems to be to change the
entry in pg_type.h without bumping catversion. That way at least it
will be right in databases initdb'd after beta2.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 28, 2014 at 4:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
One of these doesn't belong:
postgres=# select typname, typcategory from pg_type where typispreferred;
typname | typcategory
-------------+-------------
bool | B
text | S
oid | N
float8 | N
inet | I
timestamptz | D
interval | T
varbit | V
pg_lsn | U
(9 rows)Was there any actual rationale to this, or was it just somebody who did
not understand what that bit is for?
Looks like an oversight of the pg_lsn patch. You could blame me for
that I suppose...
I think it's probably mostly harmless given the lack of casts to or from
pg_lsn, but it's still a darn bad idea to have any preferred types in the
'U' category. If we leave it like this it will bite us in the rear
eventually.
The most expedient response at this late date seems to be to change the
entry in pg_type.h without bumping catversion. That way at least it
will be right in databases initdb'd after beta2.
Agreed. Attached patch fixes that, but I am sure that you already
figured it out.
--
Michael