Message-ID: <3D632578.107@joeconway.com>
Date: Tue, 20 Aug 2002 22:30:32 -0700
From: Joe Conway <mail@joeconway.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: Proposal: make "opaque" obsolete
References: <18530.1029866880@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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