Re: WIP: Range Types - Mailing list pgsql-hackers

From Robert Haas
Subject Re: WIP: Range Types
Date
Msg-id AANLkTim88W7p3_EPC9eR+0fHS6zQzvZmU3U9T0uUw30r@mail.gmail.com
Whole thread Raw
In response to Re: WIP: Range Types  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: WIP: Range Types  ("David E. Wheeler" <david@kineticode.com>)
Re: WIP: Range Types  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
On Wed, Jan 12, 2011 at 2:16 AM, Martijn van Oosterhout
<kleptog@svana.org> wrote:
> On Tue, Jan 11, 2011 at 09:24:08PM -0500, Robert Haas wrote:
>> commit 6c412f0605afeb809014553ff7ad28cf9ed5526b
>> Author: Tom Lane <tgl@sss.pgh.pa.us>
>> Date:   Sun May 1 18:56:19 2005 +0000
>>
>>     Change CREATE TYPE to require datatype output and send functions to have
>>     only one argument.  (Per recent discussion, the option to accept multiple
>>     arguments is pretty useless for user-defined types, and would be a likely
>>     source of security holes if it was used.)  Simplify call sites of
>>     output/send functions to not bother passing more than one argument.
>>
>> ...but I don't understand the motivation behind it.
>
> IIRC, the issue is that a type output function has to interpret a
> Datum. Type output functions can also be called by users, so it is not
> guarenteed that the given OID would actually match the type of the
> Datum given. Hence the decision that the output function must be able
> to determine itself what kind of Datum it is dealing with.
>
> Thought experiment: the datum is an integer, but the oid says it's a
> pass-by-ref datum. Now the code may now to use the integer to derefence
> an arbitrary place in memory.

I guess that begs the question of why we need to allow users to call
type output functions directly.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Add support for logging the current role
Next
From: Bruce Momjian
Date:
Subject: libpq documentation cleanups (repost 3)