Re: pg_get_serial_sequence is inconsistent - Mailing list pgsql-general

From Bruce Momjian
Subject Re: pg_get_serial_sequence is inconsistent
Date
Msg-id 200702140432.l1E4WHg15152@momjian.us
Whole thread Raw
In response to pg_get_serial_sequence is inconsistent  ("Frank Millman" <frank@chagford.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: suggestions on improving a query
Next
From: Mike Harding
Date:
Subject: Timestamp/Timezone - does this make sense?