Re: [HACKERS] DROPping tables with SERIALs
| От | Vadim Mikheev |
|---|---|
| Тема | Re: [HACKERS] DROPping tables with SERIALs |
| Дата | |
| Msg-id | 365EF1CD.DD1AC692@krs.ru обсуждение исходный текст |
| Ответ на | Re: [HACKERS] DROPping tables with SERIALs (jwieck@debis.com (Jan Wieck)) |
| Ответы |
Re: [HACKERS] DROPping tables with SERIALs
|
| Список | 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 по дате отправления: