pg_get_serial_sequence is inconsistent

Lists: pgsql-hackers
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: pg_get_serial_sequence is inconsistent
Date: 2004-10-28 05:12:46
Message-ID: 28121.1098940366@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

pg_get_serial_sequence() does dequoting/downcasing on its relation-name
argument, but not on its column-name argument.

regression=# create table "FOO" ("Ff1" serial);
NOTICE: CREATE TABLE will create implicit sequence "FOO_Ff1_seq" for serial column "FOO.Ff1"
CREATE TABLE
regression=# select pg_get_serial_sequence('FOO','Ff1');
ERROR: column "Ff1" of relation "foo" does not exist
regression=# select pg_get_serial_sequence('"FOO"','Ff1');
pg_get_serial_sequence
------------------------
public."FOO_Ff1_seq"
(1 row)

regression=# select pg_get_serial_sequence('"FOO"','"Ff1"');
ERROR: column ""Ff1"" of relation "FOO" does not exist
regression=#

This seems pretty inconsistent. I was expecting to find that it broke
pg_dump, as well, but it looks like pg_dump is expecting exactly
this behavior.

Should we change it? We need the quote-aware behavior for the relation
name (because that could be schema-qualified) so the choices seem to be
status quo or add dequoting/downcasing to the column name argument.

regards, tom lane


From: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_get_serial_sequence is inconsistent
Date: 2004-10-28 05:44:27
Message-ID: 4180873B.9070904@familyhealth.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> pg_get_serial_sequence() does dequoting/downcasing on its relation-name
> argument, but not on its column-name argument.
>
> regression=# create table "FOO" ("Ff1" serial);
> NOTICE: CREATE TABLE will create implicit sequence "FOO_Ff1_seq" for serial column "FOO.Ff1"
> CREATE TABLE
> regression=# select pg_get_serial_sequence('FOO','Ff1');
> ERROR: column "Ff1" of relation "foo" does not exist
> regression=# select pg_get_serial_sequence('"FOO"','Ff1');
> pg_get_serial_sequence
> ------------------------
> public."FOO_Ff1_seq"
> (1 row)

I presume the reason for that is that the first paramater can be qualified:

select pg_get_serial_sequence('"public"."FOO"', 'Ff1');

Chris


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_get_serial_sequence is inconsistent
Date: 2004-10-28 14:39:06
Message-ID: 1880.1098974346@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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 ...

regards, tom lane


From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_get_serial_sequence is inconsistent
Date: 2004-10-28 23:50:18
Message-ID: 200410282350.i9SNoIi05161@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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 ...

That behavior does seem strange to me. Would make it consistent have
any downsides? If not, we should do it.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073


From: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_get_serial_sequence is inconsistent
Date: 2004-10-29 01:32:32
Message-ID: 41819DB0.8030301@familyhealth.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> 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 ...

I'm happy to have it fixed or changed :) I was just pointing out why it
was like it is. It uses two different parsing functions.

Chris


From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_get_serial_sequence is inconsistent
Date: 2004-11-27 06:12:03
Message-ID: 200411270612.iAR6C3B22842@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


Should we fix this or document it somewhere? It is the issue of
pg_get_serial_sequence handling upper/lower case differently for its two
arguments, if I remember correctly.

---------------------------------------------------------------------------

Christopher Kings-Lynne wrote:
> > 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 ...
>
> I'm happy to have it fixed or changed :) I was just pointing out why it
> was like it is. It uses two different parsing functions.
>
> Chris
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073