Re: ALTER TABLE ... TO ... to change related names

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dennis Björklund <db(at)zigo(dot)dhs(dot)org>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org, Jonathan Gardner <jgardner(at)jonathangardner(dot)net>
Subject: Re: ALTER TABLE ... TO ... to change related names
Date: 2003-08-30 21:45:29
Message-ID: 1692.1062279929@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

=?ISO-8859-1?Q?Dennis_Bj=F6rklund?= <db(at)zigo(dot)dhs(dot)org> writes:
> I don't understand why the serial columns sequence should be visible as
> other sequences.

Backwards compatibility, if nothing else. Are you prepared to break
every existing dump file that has
CREATE TABLE ser (f1 serial);
SELECT pg_catalog.setval('ser_f1_seq', 1, false);

> create table foo (x serial);
> select nextval('foo.x');

This conflicts with the existing provisions for accessing sequences
using ordinary schema-qualified names ('schema.sequence').

The work I would actually like to see getting done in this area is
the existing TODO item about using Oracle-compatible syntax for nextval
et al, namely that you can write
sequence.nextval
or
schema.sequence.nextval
rather than nextval('sequence') or nextval('schema.sequence'). The
internal representation of such a thing could use the sequence OID to
refer to the sequence, and would thereby be inherently rename-proof
(not to mention visible to the dependency tracker, so's you couldn't
accidentally drop a sequence that's still mentioned in some default
expression). There is speculation in the archives about how we might
implement this and even arrange to auto-migrate existing schemas during
dump/reload.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-08-30 21:50:59 Re: [HACKERS] What goes into the security doc?
Previous Message Scott Lamb 2003-08-30 21:34:53 Re: Date input changed in 7.4 ?