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