Re: question about deparsing const node and its typmod

From: "Tao Ma" <feng_eden(at)163(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: question about deparsing const node and its typmod
Date: 2009-04-02 03:13:52
Message-ID: gr1ahp$k63$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thank you for your reply to the question. If it was chosen to reproduce the
actual semantics of the expression in various contexts, I think the bpchar
type of 'abc'::bpchar is surprised me. Is it really important to show the
'bpchar' if there is no any explicit casting for the column default value.

I searched for 'default' and 'bpchar' in CVS history and failed
to figure out the reason why the 'bpchar' need to be displayed. Maybe for
the CHECK expression or the default value including operator or function the
category type can be extremely usefuly to help us understand the type conversion
result.

Is it possible to omit the bpchar or something like it, if it is a const node
for the default value?

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:18655(dot)1238258851(at)sss(dot)pgh(dot)pa(dot)us(dot)(dot)(dot)
> "Tao Ma" <feng_eden(at)163(dot)com> writes:
>> CREATE TABLE "t" (c1 CHAR(5) DEFAULT 'abc',
>> c2 CHAR(5) DEFAULT 'abc'::CHAR(5));
>
>> SELECT pg_get_expr(adbin, adrelid)
>> FROM pg_attrdef
>> WHERE adrelid = (SELECT oid FROM pg_class WHERE relname = 't');
>
>> pg_get_expr
>> ---------------------
>> 'abc'::bpchar
>> 'abc'::character(5)
>> (2 rows)
>
>> so I am courious about is there any possibility to make the default value
>> for c1 look like the default value for c2.
>
> That behavior is very carefully chosen to reproduce the actual semantics
> of the expression in various contexts. We can't change it just to make
> it "look prettier".
>
> If you check the CVS history of ruleutils.c to see when that logic got
> changed, you should be able to locate pgsql-hackers discussions that
> worked out what the behavior has to be. I seem to remember that the
> most recent iteration had to do with making sure that ALTER COLUMN TYPE
> had unsurprising side-effects on the column's default.
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message maosen.zhang 2009-04-02 04:00:08 hstore bug and repair method
Previous Message Tom Lane 2009-04-02 02:58:24 Re: protect dll lib initialisation against any exception, for 8.5