Re: Happy column adding (was RE: [HACKERS] Happy column dropping)
От | Don Baccus |
---|---|
Тема | Re: Happy column adding (was RE: [HACKERS] Happy column dropping) |
Дата | |
Msg-id | 3.0.1.32.20000125080125.00f7f160@mail.pacifier.com обсуждение исходный текст |
Ответ на | Happy column adding (was RE: [HACKERS] Happy column dropping) (Peter Eisentraut <e99re41@DoCS.UU.SE>) |
Ответы |
Re: Happy column adding (was RE: [HACKERS] Happy column dropping)
Re: Happy column adding (was RE: [HACKERS] Happy column dropping) Re: Happy column adding (was RE: [HACKERS] Happy column dropping) RE: Happy column adding (was RE: [HACKERS] Happy column dropping) |
Список | pgsql-hackers |
At 11:55 AM 1/25/00 +0100, Peter Eisentraut wrote: >On Tue, 25 Jan 2000, Hiroshi Inoue wrote: > >> Even default is not allowed in ADD COLUMN now. >> There may be other reasons why they aren't allowed. > >It's not a matter of *allowed*, it's a parsing deficiency. The fact that >there was a default declared gets silently ignored. If y'all allow ;) I >would like to fix that (have already started a bit) by perusing the code >in parse_func.c:transformCreateStmt and do the same for the alter table >add column part. Maybe and add/drop constraint will come out in the end as >well. However, heap_getattr still won't see the default since it simply checks to see of the attribute number falls off the end of the tuple and then returns null. There's no provision for then pulling out the default value and returning it instead. I think this is why Tom was implying that add column should really alter the table? A fully-featured "add column" feature would be very nice, indeed. - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
В списке pgsql-hackers по дате отправления: