> 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.
Without actually looking at the code, I'm pretty sure that the
unspecified constant string in the first insert above is getting
interpreted as a string of type UNKNOWN. Apparently it actually tests
for the length of the string and tries to do a "pass by value" if it can
fit.
I don't see this as being a big win, and if you would find it easier we
could try to track it down and make UNKNOWN a pass by reference always.
btw, the call to bpchar(bpchar,int4) is part of my new type coersion
code; this is the first release that will actually check and truncate
strings as they are being stored into a table. In previous releases
longer strings which were the result of, for example, a concatenation
were not length-checked on storage into the table.
Anyway, let me know what you'd like...
- Tom
