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.
