Re: [HACKERS] DROPping tables with SERIALs

From: Vadim Mikheev <vadim(at)krs(dot)ru>
To: Jan Wieck <jwieck(at)debis(dot)com>
Cc: Jan Iven <j(dot)iven(at)rz(dot)uni-sb(dot)de>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] DROPping tables with SERIALs
Date: 1998-11-27 18:39:09
Message-ID: 365EF1CD.DD1AC692@krs.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 1998-11-27 18:56:03 Re: [HACKERS] copy
Previous Message Tom 1998-11-27 17:47:55 Re: [HACKERS] Re: Mysql 321 - Mysql 322 - msql