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