Craig Ringer <craig@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
