Tom Lane wrote:
> About I/O behavior: the pg_type entries for these pseudo-types will have to
> have typinput and typoutput functions. In general these I/O routines must
> just throw errors. Otherwise you could break the intended type safety by
> supplying user-written constants. For instance, the present definition of
> RECORD is wrong (sorry Joe) because it uses oidin and oidout; so I could
> write "SELECT foo('42'::record)" and thereby crash a function expecting
> RECORD. Not that there will be any such function, but the analogous case
> with, say, INTERNAL would be bad news.
Sorry I've been unable to be very involved today. Anything you want me
to do here?
> An exception is that void_out should succeed and just return an empty string;
> this allows functions-returning-void to be called by SELECT and behave
> reasonably. Less obviously, void_in should succeed (and return nothing
> interesting, probably just a zero datum; it can ignore its input). This
> allows plpgsql functions to be defined to return VOID.
This will be useful if/when we want to implement "CALL stored_proc;"
> Should we throw a NOTICE stating that opaque is deprecated if a trigger
> is declared with opaque? Or should we wait a release or two for that?
I'd throw the NOTICE now.
Joe
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
