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 <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org/