Re: ALTER TABLE ... TO ... to change related names - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: ALTER TABLE ... TO ... to change related names
Date
Msg-id 3F5120A4.7040302@dunslane.net
Whole thread Raw
In response to Re: ALTER TABLE ... TO ... to change related names  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Having just had to add serial columns to 3 columns, and found it 
moderately painful, I have had these thoughts: . We need "alter table foo add column bar serial" - wasn't someone 
working on that? . What about a rowid type? Wouldn't have to be in any order, just 
unique. Could be an existing OID value, or something similar with no 
wraparound? That would account for what I suspect is 90% of the cases 
where serial fields are needed.

cheers

andrew

Tom Lane wrote:

>Dennis Björklund <db@zigo.dhs.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
>
>---------------------------(end of broadcast)---------------------------
>TIP 8: explain analyze is your friend
>
>  
>



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: database corruption
Next
From: Tom Lane
Date:
Subject: Re: Is it a memory leak in PostgreSQL 7.4beta?