Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group