From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plpgsql versus domains |
Date: | 2015-02-27 18:50:03 |
Message-ID: | CA+TgmoZG3BbhKUsT+U4MBwNp_UnYFO9sg+XsOBt7LSnKQYdFAg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
I didn't realize that this issue had even been discussed before...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Corey Huinker | 2015-02-27 18:50:22 | Re: [POC] FETCH limited by bytes. |
Previous Message | Tom Lane | 2015-02-27 18:45:22 | Re: star schema and the optimizer |