Re: Changing column types... - Mailing list pgsql-hackers

From Thomas Lockhart
Subject Re: Changing column types...
Date
Msg-id 3CAD2ABF.E93DFDDB@fourpalms.org
Whole thread Raw
In response to Re: Changing column types...  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
Responses Re: Changing column types...  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > A few integer values are reserved values in abstime, to allow
> > implementation of infinity, -infinity, etc.
> Does this mean that hacking the type of an int4 column to become abstime is
> a bad idea?
> Yes in theory - no in practice?

Hmm. I assume that this is in the context of an "officially supported"
conversion strategy? I'm afraid I am not recalling the details of these
threads; my brain does not hold as much as it used to ;)

Anyway, if we are thinking of allowing some types to be converted in
place without actually modifying the contents of tuples, then for this
case the risks are relatively small afaicr. The reserved values are at
the high and low ends of the integer range, so there are some large (in
the absolute sense) integer values which would take on some unexpected
interpretations for an abstime value.

That said, I'm not sure why we would want to bother with hacking things
in this way (but if I recalled the details of the threads maybe I
would?).

istm that the general strategy for changing column types would require
marking a column as dead and adding a new column to replace it, or
writing an atomic copy / modify / replace operation for tables which
modifies tuples as it proceeds, or ?? Just because we may allow a hack
for text types because they happen to have a similar/identical storage
structure doesn't necessarily mean that it is a good design for the
general case. But you've probably already covered that territory...
                    - Thomas


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: timeout implementation issues
Next
From: Gavin Sherry
Date:
Subject: Re: Changing column types...