Re: Strange behavior regarding temporary sequences

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: hf99(at)protecting(dot)net
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Strange behavior regarding temporary sequences
Date: 2003-10-03 20:36:00
Message-ID: 782.1065213360@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Harald Fuchs <nospam(at)sap(dot)com> writes:
> test=# create temp sequence ts;
> CREATE SEQUENCE
> test=# create table tt1 (id int not null default nextval ('ts'), str varchar(255) not null);
> CREATE TABLE

> Although what PostgreSQL (7.3.4) does is perfectly reasonable, I find
> it somewhat unclean. Since we now disallow FOREIGN KEYs between temp
> and normal tables, we might also disallow using temp sequences with
> normal tables.

That's fairly impractical given that PG doesn't know that nextval('ts')
represents a sequence reference at all. (The nextval() function knows
it, but I'd strongly resist any attempt to hard-wire assumptions about
nextval() into the rest of the system.)

There has been some talk of supporting the Oracle sequence syntax
ts.nextval, which would expose the sequence reference in a form the
system could recognize. In the present state of the system, that would
cause your DEFAULT expression to get dropped when the temp sequence
went away (same result as DROP ... CASCADE issued manually).

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-10-03 21:37:52 Re: Thoughts on maintaining 7.3
Previous Message Alvaro Herrera 2003-10-03 19:35:45 Re: 7.4 status