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

> "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> > Would it be possible to update the system tables, so that cash_out does not take
> > opaque but really takes type money ?
>
> That is part of the solution, but only part: we have hundreds of
> functions that take "opaque" because we don't currently have any way
> to declare what they really take.

So the idea is, that input functions take cstring type, and output functions
take the explicit type they are designed for ?
Is there anything that can be done vs that types only exist after the functions ?
e.g. create it in one tx with constraints deferred ? Or is that no issue ?

>  (In particular, all the typinput
> functions are like that --- so fixing typoutput functions isn't plugging
> even half of the gap.)
>
> See my proposal to make "opaque" obsolete.

Yes, it is great that you will look into this !!
About the names, would it be good to use SQL99 reserved words ? (e.g. ROW for tuple)
nice url: http://developer.mimer.se/validator/sql-reserved-words.tml

count(*)         --> anynumeric  :-) (two flies with one strike)
NULL/NONNULL    --> null|nullvalue|anynull ? We only need this internally, no ?

Hard to say what is good for those names imho, don't like "anytype" :-(
(maybe even leave that opaque for now)

I like "cstring", "void" and "internal".
Maybe "anyarray" instead of "anyarraytype".
And I would prefer "row" instead of "tuple".

Andreas

"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> Hard to say what is good for those names imho, don't like "anytype" :-(

How about "any"?  It's a reserved word per SQL99, I think.

> I like "cstring", "void" and "internal". 

Okay.

> Maybe "anyarray" instead of "anyarraytype".

That would match with "any".

> And I would prefer "row" instead of "tuple".

I'm leaning towards agreeing with Stephan: we should use typename
"trigger" to declare triggers.  "Tuple" (or "row") is strictly correct
only for BEFORE triggers, not AFTER triggers, so it's a bit of a
misnomer for triggers anyhow.

I'm now also toying with inventing a pseudotype just for procedural
language handlers, which are currently "foo() returns opaque".  If we
want the type system to catch misuses of trigger functions, we should
want it for handlers too.  Maybe name this type "language_handler"?
(I had thought we could declare handlers to return "internal", but we
can't do that without breaking type safety.  We don't want *any* way
for an SQL construct to look like it returns type "internal".)
        regards, tom lane