Re: pg_get_serial_sequence is inconsistent
От | Bruce Momjian |
---|---|
Тема | Re: pg_get_serial_sequence is inconsistent |
Дата | |
Msg-id | 200702140432.l1E4WHg15152@momjian.us обсуждение исходный текст |
Ответ на | pg_get_serial_sequence is inconsistent ("Frank Millman" <frank@chagford.com>) |
Список | pgsql-general |
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. +
В списке pgsql-general по дате отправления: