Re: Allowing implicit 'text' -> xml|json|jsonb (was: PL/pgSQL 2)

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, 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 (was: PL/pgSQL 2)
Date: 2014-09-05 20:07:13
Message-ID: CAHyXU0yFjaAga1awQgbAEzLHLveC3TUMcEf1Fht=WVhscjFynQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 5, 2014 at 2:04 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> On 09/05/2014 12:04 AM, Pavel Stehule wrote:
>>
>> But some missing casts are well - I found lot performance issues based
>> on using wrong data types - integers, dates in text column.
>
> Of course! That's why the default implicit casts were removed, and for
> good reason. I'm only talking about a narrow class of a few specific types.
>
> I think maybe a _few_ types need to be implicitly convertable from text,
> but that's about it.
>
> text -> jsonb
> text -> json
> text -> xml
> text -> hstore
> text -> uuid
> text -> (user defined enum)
>
> ... mainly because otherwise app devs need frustrating workarounds (or
> giving up on the PostgreSQL native types and just using 'text' columns),
> and because in all these cases PostgreSQL will validate the input.

That seems pretty reasonable. If you do that along with redefining
certain functions like lpad() to take "any" instead of text you'd
eliminate most of the headaches.

merlin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Oskari Saarenmaa 2014-09-05 20:38:11 [PATCH] parser: optionally warn about missing AS for column and table aliases
Previous Message Pavel Stehule 2014-09-05 19:54:25 VIP: explain of running query