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.
signature.asc
Description: Digital signature
