On Wed, Dec 20, 2006 at 01:39:58AM +0000, Tom Dunstan wrote:
> Not with this patch, and AFAIK not possible generally, without writing 
> separate I/O functions for each type. I'd love to be able to do that, 
> but I don't think it's possible currently. The main stumbling block is 
> the output function (and cast-to-text function), because output 
> functions do not get provided the oid of the type that they're dealing 
> with, for security reasons IIRC. It was never clear to me why I/O 
> functions should ever be directly callable by a user (and hence open to 
> security issues), but apparently it was enough to purge any that were 
> designed like that from the system, so I wasn't going to go down that 
> road with the patch.

I worked around this in taggedtypes by indeed creating seperate copies
of the i/o functions on demand and at execution time looking up the
required type from the function signiture.

The only solution indeed is to change the calling convention if the I/O
functions so that the relevent datatype oid stored in a safe place,
that isn't set for normal function calls.

BTW, being able to call type i/o functions directly is very useful. For
example date_in(text_out(blah)) is a form of cast between types that
don't usually have a cast. If you change the calling convention as
indicated, that trick will still work, just not for types with the
restricted i/o functions.

Also, it's not just I/O functions that are the issue, consider the
enum-to-integer cast.

Have a nice day,
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to 
> litigate.

Attachment: signature.asc
Description: Digital signature

Reply via email to