Обсуждение: question about deparsing const node and its typmod
Hi,
Recently, I am reading the postgres codes, and I have a question about the
deparsing some expressions which is contains Const node. The following SQL
will retrieve the definition stored by postgres database for table "t":
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)
Postgres will emit a implicit coercion for the default value of c1 column
before the definition node can be stored in system catalog pg_attrdef.
To retrieve a human-readable definition for the default value, pg_get_expr()
will call get_func_expr() to display the default value. get_func_expr()
will omit the implicit function and return the first argument barely. The
default value for column c2 is pretty than the default value for column c1,
so I am courious about is there any possibility to make the default value
for c1 look like the default value for c2.
If we do not concern the compatible with old system, is it possible to
modify the function transformExpr() or something else to archieve the the
'pretty'(may be not pretty at all for someone) format? It seems assign the
correct typmod to Const node during transform phase is possible, but most
of time it is meaningless. typmod plays an important role during the
process of coercion decision, it seems the coercion will absence iff the
type and typmod is same.
Thanks in advance,
Tao Ma
"Tao Ma" <feng_eden@163.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
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@sss.pgh.pa.us> writes:18655.1238258851@sss.pgh.pa.us... > "Tao Ma" <feng_eden@163.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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
"Tao Ma" <feng_eden@163.com> writes:
> Is it really important to show the
> 'bpchar' if there is no any explicit casting for the column default value.
Yeah. We cannot say "char" because per SQL spec, that means "char(1)",
but there mustn't be a restriction to a single character here.
regression=# select 'abc'::char;bpchar
--------a
(1 row)
regression=# select 'abc'::bpchar;bpchar
--------abc
(1 row)
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Tao Ma" <feng_eden@163.com> writes: >> Is it really important to show the 'bpchar' if there is no any >> explicit casting for the column default value. > > Yeah. We cannot say "char" because per SQL spec, that means > "char(1)", but there mustn't be a restriction to a single character > here. Tangential point: Maybe bpchar should be better documented for users, since it does occassionally show up in user visible places. The only current description that I could find (short of digging into the source code) is here: http://www.postgresql.org/docs/8.3/interactive/typeconv-query.html Perhaps a mention should be added here, as it might be where people would go looking for it?: http://www.postgresql.org/docs/8.3/interactive/datatype-character.html -Kevin