Re: transformations between types and languages

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

In response to

Responses

Browse pgsql-hackers by date

  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