On Tue, 2002-08-06 at 11:02, Christopher Kings-Lynne wrote:
> > But we *have* drop column.
>
> I know that....I think I must have been on crazy pills when I mentioned it
> in regards to DROP COLUMN...
>
> > If we don't do attlognum for 7.3, there's little point in doing it at
> > all. By the time 7.4 comes out, clients that formerly expected a
> > consecutive series of attnums will have found some way to cope.
>
> I think that what Hannu is saying is that if we implemented changing column
> type with a drop and an add, all queries that used to go 'select * from'
> would return the modified column at the end of the list of columns instead
> of in its original position.
There is at least one type of change that can be safely done in-place,
namely making variable length types longer (varchar(2) --> varchar(5)).
Making them shorter would be doable in-place, but then there are two
ways to go -
1. we check that the data fits the new length
2. i/o funtions would enforce length
the 2. way has an unexpected behaviour if we first make a field shorter
and then longer again.
> > I'm not sure that I feel any strong sense of urgency about this ---
> > 7.3 will break clients that examine the system catalogs in many ways,
> > and this doesn't seem like the nastiest of 'em.
It's not about inspecting system catalogs by clients, it is the change
in select * after a column type change (say from float to numeric(15,2))
if done by "add column + update + drop column + rename column" if we had
lognums, we could do "move column" as a final step.
Using the above scenario we already can do "alter table alter column
type" manually, so I'd suggest that implementing attlognum (move column)
gives more additional functionality than putting in a frontend to do
move column manually.
The "drop column + rename column + move column" could also be rolled
into one "replace column" command ;)
-----------
Hannu
