Re: DROP COLUMN
От | Hannu Krosing |
---|---|
Тема | Re: DROP COLUMN |
Дата | |
Msg-id | 1026898097.5749.10.camel@taru.tm.ee обсуждение исходный текст |
Ответ на | Re: DROP COLUMN (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: DROP COLUMN
|
Список | pgsql-hackers |
On Wed, 2002-07-17 at 08:26, Tom Lane wrote: > Hannu Krosing <hannu@tm.ee> writes: > > Also, as we have nothing like Oracles ROWNR, I think it will be quite > > hard to have colnums without gaps in the system views, so we could > > perhaps have a stopgap solution of adding logical column numbers ( > > (pg_attribute.attlognum) that will be changed every time a col is > > added/dropped just for that purpose. > > [ thinks... ] I don't believe this would make life any easier, really. > Inside the backend it's not much help, because we still have to look > at every single attnum reference to see if it should be logical or > physical attnum. I meant this as a workaround for missing ROWNR pseudocolumn. All backend functions would still use real attnum's. And I doubt that backend will ever work though system views. Adding them should touch _only_ CREATE TABLE, ADD COLUMN, DROP COLUMN plus the system views and possibly output from SELECT(*), if we allow logical reordering of columns by changing attlognum. Of course we would not need them if we had ROWNR (or was it ROWNUM ;), except for the hypothetical column reordering (which would be useful for ALTER COLUMN CHANGE TYPE too) > On the client side it seems promising at first sight > ... but the client will still break if it tries to correlate the > logical colnum it sees with physical colnums in pg_attrdef and other > system catalogs. One can alway look it up in pg_attribute ;) Just remember to use attlognum _only_ for presentation. > Bottom line AFAICT is that it's a lot of work and a lot of code > to examine either way :-( Yes, I see that it can open another can of worms . -------------- Hannu
В списке pgsql-hackers по дате отправления: