Thread: Re: [SQL] how to change the type
OK, I'm kind of interested now in how the variable length attributes are actually stored on disk, that you are able to increase them, but not decrease? I would have thought the other way around? Chris > -----Original Message----- > From: Stephan Szabo [mailto:sszabo@megazone23.bigpanda.com] > Sent: Friday, 7 December 2001 10:05 AM > To: Christopher Kings-Lynne > Cc: tinar; pgsql-sql@postgresql.org > Subject: RE: [SQL] how to chane the type > > > > On Fri, 7 Dec 2001, Christopher Kings-Lynne wrote: > > > What's the essential problem with changing column types in > postgres? Is it > > similar to the DROP COLUMN problem? > > > > If the answer is that the table format only has allocated > enough space per > > row for the existing type, then how is it possible that > Stephen's hack below > > will not break things? > > The hack below only works to change the max length of variable length > attributes and only upward. I'd be very wary of trying to change the real > type of a value except between ones that are bitwise compatible (like I > think varchar and text are technically, but I'm not sure). > > > > The best way is to recreate the table and rename > > > them around. If you *REALLY* don't want to do > > > that and have a recent backup (yes, I'm serious), > > > you can muck with pg_attribute and change > > > atttypmod for the attribute in question > > > (from 14 to 34). >
On Fri, 7 Dec 2001, Christopher Kings-Lynne wrote: > OK, I'm kind of interested now in how the variable length attributes are > actually stored on disk, that you are able to increase them, but not > decrease? > > I would have thought the other way around? IIRC, the values are stored as length + data. I think char() might do wierd things (I don't know if the trailing spaces are stored), but varchar() and text should be expandable because anything that could have fit before should still fit and look the same. Going down is problematic, because if you have a varchar(5) field where one value is say 'abcd' and you make it varchar(3) what happens?
Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> IIRC, the values are stored as length + data. I think char() might
> do wierd things (I don't know if the trailing spaces are stored), but
> varchar() and text should be expandable because anything that could have
> fit before should still fit and look the same.
Yup, exactly.
> Going down is
> problematic, because if you have a varchar(5) field where one value is say
> 'abcd' and you make it varchar(3) what happens?
What would actually happen right now is nothing: the value would still
be 'abcd' and would still read out that way. The 3-char limit would
only get enforced during inserts and updates of the column.
char(N) does store the trailing spaces, so altering N would give
unwanted results: again, existing values would read out with the old
width until updated. You could fix this by issuing
UPDATE tab SET col = col
after tweaking the pg_attribute.atttypmod value. (AFAICS, any "clean"
implementation would have to do just that internally, with the same
unpleasant space and speed implications as we've discussed for DROP
COLUMN.)
regards, tom lane
On Fri, 7 Dec 2001, Tom Lane wrote: > Stephan Szabo <sszabo@megazone23.bigpanda.com> writes: > > Going down is > > problematic, because if you have a varchar(5) field where one value is say > > 'abcd' and you make it varchar(3) what happens? > > What would actually happen right now is nothing: the value would still > be 'abcd' and would still read out that way. The 3-char limit would > only get enforced during inserts and updates of the column. That's what I figured, but I also assume that'd be "wrong" in a pure sense since the value is invalid for the new datatype, so I figure its safer to say up only. :)
> char(N) does store the trailing spaces, so altering N would give > unwanted results: again, existing values would read out with the old > width until updated. You could fix this by issuing > > UPDATE tab SET col = col > > after tweaking the pg_attribute.atttypmod value. (AFAICS, any "clean" > implementation would have to do just that internally, with the same > unpleasant space and speed implications as we've discussed for DROP > COLUMN.) Can I take this opportunity to give my little thought on operations like these (alter column type, drop column, etc.?) If the DBA had to issue these commands every 5 minutes, then the speed and space implications would be bad, yeah. However, if all I want to do is drop a column once every 6 months, then I don't really care that the operation might take a minute and might consume lots of disk space... Chris