Robert Haas <robertmh...@gmail.com> writes: > I think I agree Tom's position upthread: blaming the coercion seems to > me to make more sense. But if that's what we're trying to do, then > why does parse_coerce() say this?
> /* > * Set up to point at the constant's text if the input routine throws > * an error. > */ > /me is confused. There are two cases that are fundamentally different in the eyes of the system: 'literal string'::typename defines a constant of the named type. The string is fed to the type's input routine de novo, that is, it never really had any other type. (Under the hood, it had type UNKNOWN for a short time, but that's an implementation detail.) In this situation it seems appropriate to point at the text string if the input routine doesn't like it, because it is the input string and nothing else that is wrong. On the other hand, when you cast something that already had a known type to some other type, any failure seems reasonable to blame on the cast operator. So in these terms there's a very real difference between what '42'::bigint means and what 42::bigint means --- the latter implies forming an int4 constant and then converting it to int8. I think that what Peter is on about in http://archives.postgresql.org/pgsql-hackers/2012-02/msg01152.php is the question of what location to use for the *result* of 'literal string'::typename, assuming that the type's input function doesn't complain. Generally we consider that we should use the leftmost token's location for the location of any expression composed of more than one input token. This is of course the same place for 'literal string'::typename, but not for the alternate syntaxes typename 'literal string' and cast('literal string' as typename). I'm not terribly impressed by the proposal to put in an arbitrary exception to that general rule for the convenience of this patch. Especially not when the only reason it's needed is that Peter is doing the fingerprinting at what is IMO the wrong place anyway. If he were working on the raw grammar output it wouldn't matter what parse_coerce chooses to do afterwards. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
