Craig Ringer <cr...@2ndquadrant.com> writes: > On 09/05/2014 05:04 PM, Marko Tiikkaja wrote: >> I really don't like the idea of relaxing casts. And I really object to >> the notion of casting from test to date being "obviously right".
> Gah. It's obviously right to *reject* implicit conversions like > text->date. I specifically do _not_ want to add such a conversion, and > gave a list of types for which I think conversions from text are > appropriate. The only concrete argument you gave why it would be safe to allow those was that the respective datatypes perform input validation. But so does text->date, so I am failing to see any meaningful distinction there. As a larger point, validation during runtime type conversions isn't really the problem. The risk created by having an abundance of implicit casts is that the parser may choose a surprising interpretation of an expression, or be unable to choose at all because there's no clearly preferred option among multiple ambiguous possibilities. So what you'd really need to argue to claim this is safe is that there are no existing functions or operators overloaded for both text and xml (resp. jsonb, etc). And that no such ambiguous cases are likely to be wanted in the future either. A quick look in pg_operator says this already falls down for the basic comparison operators on jsonb ... >> The problem here seems to be only related to mistyped parameters. Can >> we contain the damage to that part only somehow? Or make this optional >> (defaulting to off, I hope)? > I'd love to make it affect only parameters, actually, for v3 protocol > bind/parse/execute. That would be ideal. Well, let's talk about that. Doing something with parameter type assignment seems a lot less likely to result in unexpected side-effects than introducing a dozen new implicit casts. > Right now the main workaround is to send all string-typed parameters as > 'unknown'-typed, but that causes a mess with function overload > resolution, and it's wrong most of the time when the parameter really is > just text. If you think adding implicit casts *won't* cause a mess with function overload resolution, I wonder why. Really though it seems like the question is how much clarity there is on the client side about what data types parameters should have. I get the impression that liberal use of "unknown" is really about the right thing in a lot of client APIs ... 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