Re: column ordering, was Re: [PATCHES] Enums patch v2
От | Martijn van Oosterhout |
---|---|
Тема | Re: column ordering, was Re: [PATCHES] Enums patch v2 |
Дата | |
Msg-id | 20061221164756.GG14992@svana.org обсуждение исходный текст |
Ответ на | Re: column ordering, was Re: [PATCHES] Enums patch v2 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: column ordering, was Re: [PATCHES] Enums patch v2
|
Список | pgsql-hackers |
On Thu, Dec 21, 2006 at 11:15:38AM -0500, Tom Lane wrote: > Martijn van Oosterhout <kleptog@svana.org> writes: > > Can we? For anything of any permenence (view definitions, rules, > > compiled functions, plans, etc) you're going to want the physical > > number, for the same reason we store the oids of functions and tables. > > Not if we intend to rearrange the physical numbers during column > add/drop to provide better packing. Urk! If that's what people are suggesting, I'd run away very quickly. Getting better packing during table create is a nice idea, but preserving it across add/drop column is just... evil. Run CLUSTER is you want that, I was expecting add/drop to be a simple catalog change, nothing more. > You could make a case that we need *three* numbers: a permanent column > ID, a display position, and a storage position. That's just way too complicated IMHO. It add's extra levels of indirection all over the place. I was envisiging the physical number to be fixed and immutable (ie storage position = permanent position). Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
В списке pgsql-hackers по дате отправления: