Re: RFC: Restructuring pg_aggregate
От | Bruce Momjian |
---|---|
Тема | Re: RFC: Restructuring pg_aggregate |
Дата | |
Msg-id | 200204101659.g3AGxQi23993@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: RFC: Restructuring pg_aggregate (Hiroshi Inoue <Inoue@tpf.co.jp>) |
Список | pgsql-hackers |
Hiroshi Inoue wrote: > Tom Lane wrote: > > > Hiroshi's "DROP_COLUMN_HACK" was essentially along this line, but > > I think he made a representational mistake by trying to change the > > attnums of dropped columns to be negative values. > > Negative attnums had 2 advantages then. It had a big > advantage that initdb isn't needed. Note that it was > only a trial hack and there was no consensus on the way. > It was very easy to change the implementation to use > attisdropped. OTOH physical/logical attnums approach > needed the change on pg_class, pg_attribute and so > I've never had a chance to open the patch to public. > It was also more sensitive about oversights of needed > changes than the attisdropped flag approach. > > > That means that > > a lot of low-level places *do* need to know about the dropped-column > > convention, else they can't make any sense of tuple layouts. > > Why ? As you already mentioned, there were not that many places > to be changed. > > Well what's changed since then ? Here is an old email from me that outlines the idea of having a physical/logical attribute numbering system, and the advantages. For implementation, I thought we could do most of the work by filtering what the client saw, and let the server just worry about physical numbering, except for 'SELECT *' expansion. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
В списке pgsql-hackers по дате отправления: