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

> "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 would actually stick to opaque in that case, already used in other db's.

> > I like "cstring", "void" and "internal".
>
> Okay.
>
> > Maybe "anyarray" instead of "anyarraytype".
>
> That would match with "any".

I thought you wanted it separate ?

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

Convinced.

>
> 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"?

"HANDLER" would again already be a reserved word, sounds good.

Andreas

"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
>> "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 would actually stick to opaque in that case, already used in other db's.

I want to change the name because (a) we are changing the semantics,
(b) we can't throw notices for opaque if we keep it as a valid choice.

>>> Maybe "anyarray" instead of "anyarraytype".
>> 
>> That would match with "any".

> I thought you wanted it separate ?

I meant that if the one name is "any", then making the other "anyarray"
(ie, both without "type" on the end) is consistent.
        regards, tom lane