Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in

"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> How could we then disallow it's use in other context ? Seems
> if there is no restriction, "any" will be exactly as prone to
> "wrong use" as opaque was.

Well, you can always shoot yourself in the foot by creating a C function
that misinterprets its input.  I'm not here to prevent that.  But it
won't be easy to make a crashable function without superuser privileges,
because all the PL languages will reject function definitions that use
type ANY as an argument or result (ditto the other pseudotypes, except
maybe VOID).

> 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.
Since I/O functions have to be coded in C anyway, we can disallow
OPAQUE as an argument type of PL functions without losing any backwards
compatibility.  Furthermore, *we do not have to treat OPAQUE as meaning
ANY*.  It can become a pseudo-type that's not coercion-compatible to
anything else, thus preventing any direct SQL calls of either I/O
functions or triggers that are declared in the old style.  There are
still some holes, for example you could doselect old_input_function(old_trigger_function());
and the type system wouldn't complain.  But it's a lot more nearly
watertight than before, even for functions declared with OPAQUE.
        regards, tom lane