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

From Robert Haas
Subject Re: WIP: Range Types
Date
Msg-id AANLkTimi2XL+djYjeL4wzr4VJqqKfAP_YhzqhS5pTbE4@mail.gmail.com
Whole thread Raw
In response to Re: WIP: Range Types  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: WIP: Range Types  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Jan 12, 2011 at 2:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Excerpts from Robert Haas's message of mié ene 12 13:48:27 -0300 2011:
>>> I guess that begs the question of why we need to allow users to call
>>> type output functions directly.
>
>> It used to be the case that that was the only way to run certain casts.
>> For example, see the pre-8.2 version of this:
>> http://wiki.postgresql.org/wiki/Pg_depend_display
>
>> I haven't needed to use that in a long time, but I am not sure if the
>> need has completely disappeared.
>
> The general point is that any out-of-band data transmitted to an output
> function has to be trustworthy, and it has to be available at any place
> that is going to call the output function.  The latter point tends to
> put a crimp in any ideas of this sort anyway: if you can derive the info
> you want at any arbitrary place in the system, why not derive it inside
> the output function to start with?

Under what circumstances would it be necessary to call a type output
function without knowing the data type?  I mean, you had to decide
which type output function you were going to call in the first place,
so...

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


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: arrays as pl/perl input arguments [PATCH]
Next
From: Alvaro Herrera
Date:
Subject: Re: arrays as pl/perl input arguments [PATCH]