From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RfD: more powerful "any" types |
Date: | 2009-09-09 17:17:40 |
Message-ID: | 3387.1252516660@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> On Sep 9, 2009, at 10:04 AM, Tom Lane wrote:
>> Well, yeah: it looks like a fertile source of security holes, not to
>> mention implementation difficulties (plpgsql really wants well-typed
>> expressions...). What you can do at the C level is not necessarily
>> sane to give to PL authors. I'm willing to consider a carefully
>> spec'd out proposal in this area, but "open the floodgates" ain't it.
> Security holes? Huh? What security holes would there be that you don't
> already have with anyelement?
Well, none, *if* it's defined to have exactly the same runtime behavior
as anyelement does. It sounded like you were arguing for something
looser. We could certainly define it as being just like anyelement
but not constrained to match any other argument or result (and, hence,
not usable as a result type).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-09-09 17:22:30 | Re: RfD: more powerful "any" types |
Previous Message | David E. Wheeler | 2009-09-09 17:17:09 | Re: RfD: more powerful "any" types |