Обсуждение: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in

> > 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.

I would have to use some pg_proc magic to make "any" appear there,
since the plan was to not make it visible at the sql level, no ?
If you do, you would also have to throw the notice for "any".

Again, I think leaving "any" be "opaque" and throwing the warning NOTICE
would be better. I do not think there is enough time to really see through
the implications of restricting opaque already in 7.3, (at least for me :-)

> 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.

Yes, certainly a lot of work.

Andreas

"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
>> 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.

> I would have to use some pg_proc magic to make "any" appear there,
> since the plan was to not make it visible at the sql level, no ?

Huh?  It'll be perfectly visible.

There is one little problem with calling it ANY, it turns out: that word
is fully reserved in our parser (and trying to make it less reserved
creates reduce/reduce conflicts).  So unless we go back to "anytype"
you'd have to quote the name, egcreate function foo("any") returns ...
I do prefer using "any" because that's what we have historically used
in CREATE AGGREGATE, but maybe the keyword conflict will be too
annoying.
        regards, tom lane