Re: plpgsql versus domains

2015-02-27 21:57 GMT+01:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> To some extent this is a workaround for the fact that plpgsql does type
> >> conversions the way it does (ie, by I/O rather than by using the
> parser's
> >> cast mechanisms). We've talked about changing that, but people seem to
> >> be afraid of the compatibility consequences, and I'm not planning to
> fight
> >> two compatibility battles concurrently ;-)
>
> > A sensible plan, but since we're here:
>
> > - I do agree that changing the way PL/pgsql does those type
> > conversions is scary. I can't predict what will break, and there's no
> > getting around the scariness of that.
>
> > - On the other hand, I do think it would be good to change it, because
> > this sucks:
>
> > rhaas=# do $$ declare x int; begin x := (3.0::numeric)/(1.0::numeric);
> end $$;
> > ERROR: invalid input syntax for integer: "3.0000000000000000"
> > CONTEXT: PL/pgSQL function inline_code_block line 1 at assignment
>
> If we did want to open that can of worms, my proposal would be to make
> plpgsql type conversions work like so:
>
> * If there is a cast pathway known to the core SQL parser, use that
> mechanism.
>
> * Otherwise, attempt to convert via I/O as we do today.
>

> This seems to minimize the risk of breaking things, although there would
> probably be corner cases that work differently (for instance I bet boolean
> to text might turn out differently). In the very long run we could perhaps
> deprecate and remove the second phase.
>

+1

There can be similar solution like plpgsql/sql identifiers priority
configuration. Some levels - and what you are proposing should be default.

It works perfectly - and from my view and what I know from my neighborhood,
there are no issues.

>
> regards, tom lane
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>