From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: transformations between types and languages |
Date: | 2012-05-21 17:33:50 |
Message-ID: | 2475.1337621630@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Here is a draft design for the transforms feature, which I'd like to
> work on. ...
> fromsql takes one argument of the respective type and returns internal.
> tosql is the other way around. It's the responsibility of the language
> handler to look up this information and use it. The "internal" argument
> or return value will be something specific to the language
> implementation and will likely be under the memory management of the
> language handler.
This part is absolutely not gonna do, because it breaks the security
requirement that it not be possible to generate exposed "internal"
values from the SQL level. For instance there would be no way for the
type system to forbid
plperl_to_hstore(xml_to_plpython(some_xml_value))
despite the fact that this would almost assuredly crash. The slightly
more enterprising hacker might try using these functions to feed things
like btinsert(), leading to even more merriment.
Can we use something else for the magic type here? Or find a way to
positively forbid such functions from being called from the SQL level?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-05-21 17:41:02 | Re: Why is indexonlyscan so darned slow? |
Previous Message | Brendan Jurd | 2012-05-21 17:32:09 | Re: External Open Standards |