Re: [HACKERS] DROPping tables with SERIALs - Mailing list pgsql-hackers

From Vadim Mikheev
Subject Re: [HACKERS] DROPping tables with SERIALs
Date
Msg-id 365EF1CD.DD1AC692@krs.ru
Whole thread Raw
In response to Re: [HACKERS] DROPping tables with SERIALs  (jwieck@debis.com (Jan Wieck))
Responses Re: [HACKERS] DROPping tables with SERIALs  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Jan Wieck wrote:
> 
>     Yepp.  The  serial  type  is implemented as an integer with a
>     default of nextval('tab_attr_seq') and  the  sequence  itself
>     created on the fly.
> 
>     I   think   we   should  have  an  additional  oid  field  in
>     pg_attribute that holds the oid of the created  sequence  and
>     that  is examined at drop table time to drop the serials too.
> 
>     TODO for v6.5 ?

There is another way: let's define special SERIAL type
(actually - int4) and in DeletePgAttributeTuples()
check if atttype == SERIALOID and drop sequence.

Also note that currently SERIAL doesn't work as
ppl expect - 
1. SERIAL should generate value if input value  is NULL or 0;
2. value generated should be max(this_field) + 1

We should add builtin trigger function for SERIAL...
Actually, having this function we can avoid 
SERIALOID: we could check in RelationRemoveTriggers
if tgfoid == ThisFuncOID and drop sequence.
On the other hand SERIALOID looks cleaner.

Vadim


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] Re: Mysql 321 - Mysql 322 - msql
Next
From: Tom
Date:
Subject: Re: [HACKERS] Re: Mysql 321 - Mysql 322 - msql