pg_get_serial_sequence is inconsistent
Hi all
I found the following post dated October 2004 -
Tom Lane wrote:
Christopher Kings-Lynne <chriskl ( at ) familyhealth ( dot ) com ( dot )
au> writes:
pg_get_serial_sequence() does dequoting/downcasing on its relation-name
argument, but not on its column-name argument.I presume the reason for that is that the first paramater can be
qualified:
Right. From a bare-functionality point of view there's nothing wrong
with it, it just seems inconsistent and therefore likely to trip someone
up in future.But it seems no one else cares, so I'll shut up about it ...
This inconsistency has just bitten me. Did anyone decide to fix it, or does
it still behave the same?
I am using 8.1.3. Apologies if this has been fixed in 8.2 - I could not find
anything in the Release Notes.
Thanks
Frank Millman
This has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---------------------------------------------------------------------------
Frank Millman wrote:
Hi all
I found the following post dated October 2004 -
Tom Lane wrote:
Christopher Kings-Lynne <chriskl ( at ) familyhealth ( dot ) com ( dot )
au> writes:
pg_get_serial_sequence() does dequoting/downcasing on its relation-name
argument, but not on its column-name argument.I presume the reason for that is that the first paramater can be
qualified:
Right. From a bare-functionality point of view there's nothing wrong
with it, it just seems inconsistent and therefore likely to trip someone
up in future.But it seems no one else cares, so I'll shut up about it ...
This inconsistency has just bitten me. Did anyone decide to fix it, or does
it still behave the same?I am using 8.1.3. Apologies if this has been fixed in 8.2 - I could not find
anything in the Release Notes.Thanks
Frank Millman
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
Subject: Re: [GENERAL] pg_get_serial_sequence is inconsistent
This has been saved for the 8.3 release:
Thanks
Frank
FYI, we have at least documented this behavior in 8.2.X:
<function>pg_get_serial_sequence</function> returns the name of the
sequence associated with a column, or NULL if no sequence is associated
with the column. The first input parameter is a table name with
optional schema, and the second parameter is a column name. Because
the first parameter is potentially a schema and table, it is not treated
as a double-quoted identifier, meaning it is lowercased by default,
while the second parameter, being just a column name, is treated as
double-quoted and has its case preserved. The function returns a value
---------------------------------------------------------------------------
Frank Millman wrote:
Hi all
I found the following post dated October 2004 -
Tom Lane wrote:
Christopher Kings-Lynne <chriskl ( at ) familyhealth ( dot ) com ( dot )
au> writes:
pg_get_serial_sequence() does dequoting/downcasing on its relation-name
argument, but not on its column-name argument.I presume the reason for that is that the first paramater can be
qualified:
Right. From a bare-functionality point of view there's nothing wrong
with it, it just seems inconsistent and therefore likely to trip someone
up in future.But it seems no one else cares, so I'll shut up about it ...
This inconsistency has just bitten me. Did anyone decide to fix it, or does
it still behave the same?I am using 8.1.3. Apologies if this has been fixed in 8.2 - I could not find
anything in the Release Notes.Thanks
Frank Millman
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +