> 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 1998-10-01 22:54:19|
|Subject: Re: [GENERAL] Long update query ?|
|Previous:||From: Bruce Momjian||Date: 1998-10-01 21:38:46|
|Subject: Re: [HACKERS] Proper cleanup at backend exit|