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 по дате отправления: