> Hi,
>
> while fixing the subselect parseback in the new ruleutil
> functions and checking if the output is now what's needed for
> dumping rules/views I came across a little detail in the
> parser I'm confused about.
>
> Having a table
>
> CREATE TABLE t1 (a char(20));
>
> the two statements
>
> INSERT INTO t1 VALUES ('x');
>
> INSERT INTO t1 VALUES ('x'::bpchar);
>
> produce mainly the same parsetree (where the const value 'x'
> of type 1042 is embedded into a call to bpchar(bpchar, int4)
> for the padding).
>
> But in the first case argument 1 is constbyval TRUE and in
> the second one FALSE (where I feel the second one is right
> for a bpchar const). Seems that it doesn't matter later.
I have just committed a fix for this. The parse_coerce code was not
setting the constbyval dependent on the type. There were a few other
places where this was not set properly, and those are fixed now.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026