
> > May be a plan could be to leave opaque, but throw a notice
> > when it is used in a create stmt, like:
> > NOTICE: the use of type OPAQUE should be avoided where possible 
> 
> Right, that's exactly the plan.
> 
> Actually, I think we can tighten the use of OPAQUE quite a bit, too.
> The only supported uses will be (a) as an argument or result of a
> datatype's I/O function, (b) as the result of a trigger function.

In my paper I use C functions that take "any tuple".
I do not yet see how I can do that without opaque if we don't 
have a "row" but only a "trigger" type.

Andreas

Wed, 21 Aug 2002 18:10:48 +0200
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in 
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> In my paper I use C functions that take "any tuple".
> I do not yet see how I can do that without opaque if we don't 
> have a "row" but only a "trigger" type.

For that you would have to use "any", at the moment.  This would give
you the same amount of type safety you have with "opaque", ie, none.

We could talk about adding more pseudotypes that are geared to
requirements not existing in the standard set of functions ...
but I'm going to concentrate on those first.

			regards, tom lane

Wed, 21 Aug 2002 12:18:41 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in 