Re: In-place conversion of type bool

From: "Joost Kraaijeveld" <J(dot)Kraaijeveld(at)Askesis(dot)nl>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PostgreSQL" <pgsql-general(at)postgresql(dot)org>
Subject: Re: In-place conversion of type bool
Date: 2008-08-14 05:26:16
Message-ID: 1218691576.4118.7.camel@panoramix.askesis.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi Tom,

On Wed, 2008-08-13 at 21:27 -0400, Tom Lane wrote:
> "Joost Kraaijeveld" <J(dot)Kraaijeveld(at)Askesis(dot)nl> writes:
> > The database says that it's bool implementation is char(1), just as
> > PostgreSQL does. I can copy te data OK, but I would like to change the
> > actual type of the column from char(1) to bool. Is that possible without
> > copying the column to a temporary column, dropping the old column and
> > renaming the temporary columns to the old column?
>
> ALTER TABLE ... ALTER COLUMN TYPE might help you. Use the USING clause
> if you need a non-default data conversion -- in this case it might look
> like USING (col = '1') or some such.

ALTER TABLE odbcdest ALTER COLUMN odbc_bool TYPE bool

gives:

ERROR: column "odbc_bool" cannot be cast to type "bool"

********** Error **********

ERROR: column "odbc_bool" cannot be cast to type "bool"
SQL state: 42804

>
> (This is probably not physically more efficient than making a temp
> table, however.)

Could you elaborate on this? I have tried something like this, but when
the column in question is a column that is used in foreign keys I am
forced to drop any foreign keys that point to this column. Which is quit
annoying on a 200 table database with lots of foreign keys.

TIA

--
Groeten,

Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
web: www.askesis.nl

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dale Harris 2008-08-14 05:32:11 cannot use result of (insert .. returning)
Previous Message Tom Lane 2008-08-14 03:19:56 Re: Problem escaping, nonstandard use of \\ in a string literal