Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2004-10-25 at 00:30, Tom Lane wrote:
>> And it
>> would produce exactly the same result anyway, because the only way there
>> could be implicit coercion steps at the top of the expression is because
>> step 3 put them there.
> Per your earlier comm
On Mon, 2004-10-25 at 00:30, Tom Lane wrote:
> Not without an initdb (to have another column to put it in).
We're already requiring an initdb for beta4; if this is the right way to
fix this (and I'm not insisting that it is), then ISTM we can just push
back beta4 a few days.
> And it
> would prod
On Sun, 24 Oct 2004, Tom Lane wrote:
> > (1) Accept the default's raw parsetree from the parser
> > (2) Convert it to a cooked parsetree via transformExpr()
> > (3) Add a coercion to the table's column type
>
> > Can't we save the cooked parsetree that we produced in #2?
>
> Not without an initd
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Possibly we should make ALTER COLUMN strip any implicit coercions that
>> appear at the top level of the default expression before it adds on the
>> implicit coercion to the new column datatype.
> That seems like a kludge. When processin
On Sun, 24 Oct 2004, Neil Conway wrote:
> (1) Accept the default's raw parsetree from the parser
> (2) Convert it to a cooked parsetree via transformExpr()
> (3) Add a coercion to the table's column type
>
> Can't we save the cooked parsetree that we produced in #2?
One could even save the strin
Tom Lane wrote:
Possibly we should make ALTER COLUMN strip any implicit coercions that
appear at the top level of the default expression before it adds on the
implicit coercion to the new column datatype.
That seems like a kludge. When processing a column default expression, we:
(1) Accept the defa
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 ha
Troels Arvin <[EMAIL PROTECTED]> writes:
> On Wed, 20 Oct 2004 14:07:29 -0400, Tom Lane wrote:
>> Hmm. What's going on here is that the stored default expression is
>> actually of the form
>> ('TODO'::varchar)::varchar(2)
> Would it be possible to check the compatibility of a default value for
>
Rod Taylor <[EMAIL PROTECTED]> writes:
> On Wed, 2004-10-20 at 14:07, Tom Lane wrote:
>> "PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
>>> troels=# create table lookat_feature(
>>> troels(# feature_id char(4),
>>> troels(# status varchar(2) default 'TODO'
> I think the bug is that default
On Wed, 20 Oct 2004 14:07:29 -0400, Tom Lane wrote:
> Hmm. What's going on here is that the stored default expression is
> actually of the form
> ('TODO'::varchar)::varchar(2)
Would it be possible to check the compatibility of a default value for
the associated column? Such a check might p
On Wed, 2004-10-20 at 14:07, Tom Lane wrote:
> "PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> > troels=# create table lookat_feature(
> > troels(# feature_id char(4),
> > troels(# status varchar(2) default 'TODO'
> The alternative would seem to be decreeing that this is not a bug.
>
> C
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> troels=# create table lookat_feature(
> troels(# feature_id char(4),
> troels(# status varchar(2) default 'TODO'
> troels(# );
> CREATE TABLE
> troels=# alter table lookat_feature
> troels-# alter column status type varchar(4);
> ALTER TABL
The following bug has been logged online:
Bug reference: 1290
Logged by: Troels Arvin
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0 Beta
Operating system: Linux, Fedora Core 2 + stuff from Red Hat Rawhide
Description:Default value and ALTER...TYPE
Deta
13 matches
Mail list logo
