"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> I can't reproduce this. View1.type1 has has type char(3) as expected in
> both cases, as witnessed by "CREATE VIEW f AS SELECT */type1 FROM
> view1"; \d f". How did you determine the data types?
I just did reproduce it: libpq's PQfmod() does report either the correct
typmod or -1, just as he says. You can see the difference on the
backend side by looking at the top-level targetentries in EXPLAIN
VERBOSE, so it is a backend problem and not client-side. My theory at
the moment is that there's something whacko about the planner's "use
physical tlist" optimization that's applied when it doesn't need to do
any projection (ie no computations or column rearrangements). That code
works fine in simpler cases but there's something about this view that
confuses it. Haven't dug into it in detail yet.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
