Added to TODO:
* Improve reporting of UNION type mismatches
http://archives.postgresql.org/pgsql-hackers/2007-04/msg00944.php
http://archives.postgresql.org/pgsql-hackers/2008-03/msg00597.php
---
Peter Eisentraut
Am Dienstag, 18. März 2008 schrieb Tom Lane:
Or we could apply Peter's patch more or less as-is, but I don't like
that. I don't think it solves the stated problem: if you know that CASE
branches 3 and 5 don't match, that still doesn't help you in a monster
query with lots of CASEs. I think
Peter Eisentraut [EMAIL PROTECTED] writes:
... I'm not sure about the terminology position and instance; they're
just two coordinates to get at the problem.
None of this will help if you have multiple unrelated clauses that
invoke select_common_type(), but that might be better handled using
I wrote:
Were there any objections to changing this patch so that it reports
the second expression's parser location, instead of some arbitrary
numbers? The way I'm envisioning doing it is:
1. Invent an exprLocation() function (comparable to, say, exprType)
that knows how to get the parser
Tom Lane [EMAIL PROTECTED] writes:
Or we could apply Peter's patch more or less as-is, but I don't like
that. I don't think it solves the stated problem: if you know that CASE
branches 3 and 5 don't match, that still doesn't help you in a monster
query with lots of CASEs. I think we can and
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Or we could apply Peter's patch more or less as-is, but I don't like
that. I don't think it solves the stated problem: if you know that CASE
branches 3 and 5 don't match, that still doesn't help you in a monster
query
So I was informed today that UNION types integer and text cannot be
matched. Alright, but it failed to tell which particular expressions
in this 3-branch, 30-columns-each UNION clause in a 100-line statement
it was talking about. So I made the attached patch to give some better
pointers.
Peter Eisentraut [EMAIL PROTECTED] writes:
peter=# values(0,1), (1::bigint,2), ('text'::text,3);
ERROR: 42804: VALUES types bigint at position 2 and text at position 3
cannot be matched in instance 1
I'm not sure about the terminology position and instance; they're
just two coordinates
Peter Eisentraut [EMAIL PROTECTED] writes:
None of this will help if you have multiple unrelated clauses that
invoke select_common_type(), but that might be better handled using the
parser location mechanism.
+1 on using the parser location mechanism and avoiding the terminology
problem
Gregory Stark wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
peter=# values(0,1), (1::bigint,2), ('text'::text,3);
ERROR: 42804: VALUES types bigint at position 2 and text at
position 3 cannot be matched in instance 1
I'm not sure about the terminology position and instance;
Tom Lane wrote:
+1 on using the parser location mechanism and avoiding the
terminology problem altogether.
I figured we would let the parser only point to the UNION or VALUES or
whatever word. It would be fairly cumbersome to drag the individual
expression positions down into
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
+1 on using the parser location mechanism and avoiding the
terminology problem altogether.
I figured we would let the parser only point to the UNION or VALUES or
whatever word. It would be fairly cumbersome to drag the individual
Tom Lane wrote:
For the VALUES case, the suggestion of row and column terminology
seems the right thing, but for UNION it would be better to use branch
perhaps (row certainly seems misleading). How can we make that work
without indulging in untranslatable keyword-insertion?
Another
Tom Lane [EMAIL PROTECTED] writes:
For the VALUES case, the suggestion of row and column terminology
seems the right thing, but for UNION it would be better to use branch
perhaps (row certainly seems misleading). How can we make that work
without indulging in untranslatable
14 matches
Mail list logo
