Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in - Mailing list pgsql-hackers

From Tom Lane
Subject Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Date
Msg-id 703.1029873483@sss.pgh.pa.us
Whole thread Raw
In response to Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in  ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>)
List pgsql-hackers
"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


pgsql-hackers by date:

Previous
From: Vince Vielhaber
Date:
Subject: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
Next
From: Bruce Momjian
Date:
Subject: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in