2015-02-27 21:57 GMT+01:00 Tom Lane <t...@sss.pgh.pa.us>: > Robert Haas <robertmh...@gmail.com> writes: > > On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane <t...@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 >
