Re: ALTER COLUMN/logical column position

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: ALTER COLUMN/logical column position
Дата
Msg-id 1069333457.2935.9.camel@fuji.krosing.net
обсуждение исходный текст
Ответ на Re: ALTER COLUMN/logical column position  (Andreas Pflug <pgadmin@pse-consulting.de>)
Ответы Re: ALTER COLUMN/logical column position
Re: ALTER COLUMN/logical column position
Список pgsql-hackers
Andreas Pflug kirjutas N, 20.11.2003 kell 11:40:
> Hannu Krosing wrote:
> 
> >
> >attnum is used internally to retrieve the data 
> >
> >  
> >
> Oops...
> 
> So if an additional column number is invented, it should not be a 
> logical column number, but a physical storage number for internal data 
> retrieval. 

You are just shifting the interface problems to a place needing way more
changes in the backend. There will be some problems either way.

also, tools needing knowledge should start using information schema as
much as they can, making internal reshufflings less of a problem.

> This way, the "user interface" doesn't change, and all those 
> "SELECT ... FROM pg_attribute ORDER BY attnum" continue delivering the 
> expected result.

Depending on what you expect ;)

If you expect the above to give you all active columns as orderd as they
are stored, then it does not give you what you expect.

Btw, most of these concerns (and more) were already iterated when DROP
column was done causing gaps in attnum. There were a lot of doomsday
profecies, but in the end it went quite smoothly. The tools needing
internal knowledge about storage (meaning any tool doing select .. from
pg_...) have always needed some upgrades for new verions.

IMHO, The only behaviour visible to common user we should worry about is
SELECT * , and a special column for solving this is _the_ easiest way to
do it.

-------------
Hannu



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: 4 Clause license?
Следующее
От: Dave Cramer
Дата:
Сообщение: Re: ALTER COLUMN/logical column position