Re: plpgsql versus domains
От | Pavel Stehule |
---|---|
Тема | Re: plpgsql versus domains |
Дата | |
Msg-id | CAFj8pRC-dqyoH1XSLbXyf6OiETZkvWbO=JFbJYTSgWdp61ovnQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: plpgsql versus domains (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
2015-02-27 21:57 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
+1
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane <tgl@sss.pgh.pa.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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: