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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
Cc: "Justin Clift" <justin(at)postgresql(dot)org>, "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>, "Vince Vielhaber" <vev(at)michvhf(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Date: 2002-08-20 19:58:03
Message-ID: 703.1029873483@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-08-20 20:04:32 Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Previous Message Vince Vielhaber 2002-08-20 19:52:52 @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)