Martijn van Oosterhout wrote:
Ah, OK that makes sense. An alternative solution when the signature was changed could
perhaps have been to pass one single argument, a structure appointing the data and its
associated type. My idea would work if the data and its type lived together always from the
moment its instantiated (read from disk or otherwise) and until death do them apart (or the
data is stored on disk, in which case the tupledesc knows what it is). I guess that would
imply a major rewrite and that my desire to have a RAW fixed length type isn't enough
motivation to do that :-)
On Wed, Jun 28, 2006 at 01:56:47PM +0200, Thomas Hallgren wrote:
A user that is trusted with installing a C-function in the backend is
free to scan the process memory anyway so in what way did that increase
the security? IMHO, the only relevant security in that context is to
have trusted people install trusted modules. I'm surprised that
something like that made you remove significant functionality.
You're missing the point. The type output function is not generally a
priveledged function. Think bpcharout, text_out, numeric_out, etc...
These can be called by users directly and the input to those functions
cannot be trusted.
Instead, I would like to humbly request the inclusion of a UUID datatype (or an opaque 128
bit datatype) in the core package. It's increasingly common and some databases (MS
SQLServer) already have built in support for it.
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly