Re: Allowing implicit 'text' -> xml|json|jsonb

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Marko Tiikkaja <marko(at)joh(dot)to>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Álvaro Hernández Tortosa <aht(at)nosys(dot)es>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allowing implicit 'text' -> xml|json|jsonb
Date: 2014-09-05 09:08:04
Message-ID: 54097D74.1050501@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 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.

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.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2014-09-05 09:08:48 Re: proposal: plpgsql - Assert statement
Previous Message Marko Tiikkaja 2014-09-05 09:04:31 Re: Allowing implicit 'text' -> xml|json|jsonb