From: | Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Troels Arvin <troels(at)arvin(dot)dk>, <pgsql-bugs(at)postgresql(dot)org>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] BUG #1290: Default value and ALTER...TYPE |
Date: | 2004-10-21 17:12:06 |
Message-ID: | Pine.LNX.4.44.0410211902250.2015-100000@zigo.dhs.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Thu, 21 Oct 2004, Tom Lane wrote:
> > Would it be possible to check the compatibility of a default value for
> > the associated column?
>
> I think that would introduce as many problems as it would fix. AFAICS
> the only way to make such a check is to evaluate the expression and see
> what happens.
The problem in the reported case was that the default value was a string
and pg infered that the default value should be a varchar(2) because that
was the column type. The problem I assume is only when the type is unknown
for pg, for values with a known type I hope that is the type that is used.
The typecast to the column type should be added on when we use the default
value and not before.
Maybe one could come up with some method to give the default value the
most general type. For a string we could give it the type text, for a
number we could give it say the smallest int type that fits it (when it is
an integer).
If one have a default value like '2' it would get the type text but that
would still work even if the column is a int column, wouldn't it?
I assume here that we must give the default value a real type. Values of
type unknown are hard to handle.
--
/Dennis Björklund
From | Date | Subject | |
---|---|---|---|
Next Message | Rodrigo Ferraz | 2004-10-21 18:50:28 | Instalation ! |
Previous Message | Tom Lane | 2004-10-21 14:58:41 | Re: BUG #1290: Default value and ALTER...TYPE |
From | Date | Subject | |
---|---|---|---|
Next Message | simon | 2004-10-21 17:16:01 | Re: Re: Why frequently updated tables are an issue |
Previous Message | Jim C. Nasby | 2004-10-21 17:11:05 | Re: SQL-Invoked Procedures for 8.1 |