Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Shouldn't we at least add the one or two exemplary statements that
> failed so we have some sort of coverage of the problem?
We could, but I'm unexcited about it. The known failures are an
extremely narrow case: we're trying to evaluate expressions (either
CHECK constraints or index expressions) over a tuple proposed to be
inserted into a relation. But the TupleDesc that's been supplied to
the evaluator is not the tuple descriptor of the target relation,
it's a descriptor generated on-the-fly from the target list of the
plan tree (by ExecTypeFromTL). And the target list includes some
constants, and our nodetree representation for constants fails to
preserve typmod knowledge, and so ExecTypeFromTL produces atttypmod
-1 for this column, and the security check didn't like that because
the Var it was checking had a nondefault typmod.
When the first reports came in, I thought seriously about fixing it
by forcing the target relation's real tupdesc (from its relcache entry)
to be used in this context instead of a generated tupdesc. I concluded
that it was too likely that there were other cases where we were
evaluating expressions against generated tuples, and we had to back off
the strength of the security check instead. I do not actually have any
specific examples, but I think it's fairly pointless to add a regression
test that covers this one narrow scenario when there are probably lots
of others.
I'm not especially a fan of the testing philosophy that says you
memorialize each individual past mistake as a permanent regression test
--- I think that just bloats the tests, and test bloat is a bad thing
because it discourages people from running the tests. (MySQL's
regression tests currently require about an hour on a fast machine.
Somehow this has not helped them to achieve a low bug rate...) I do
agree with adding a test when you think it is likely to be able to catch
a whole class of errors, or even a specific error if it seems especially
likely to recur, but right now I'm not seeing how we do that here.
BTW, I think a good case could be made that the core of the problem
is exactly that struct Const doesn't carry typmod, and thus that we
lose information about constructs like 'foo'::char(7). We should fix
that, and also anywhere else in the expression tree structure where
we are discarding knowledge about the typmod of a result. This has
got some urgency because of Teodor's recent work on allowing user
defined types to have typmods --- we can expect massive growth in the
number of scenarios where it matters.
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
