Re: WIP: Range Types

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: Range Types
Date: 2011-01-12 19:52:21
Message-ID: 654.1294861941@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jan 12, 2011 at 2:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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...

If the out-of-band info is going to be limited to the type OID, you
might as well put it in the object, ie, follow the same solution we're
already using for arrays. Jeff's problems are already plenty large
enough without insisting that he invent a new, precedent-free solution
for this problem (*and* break every single output-function call site in
both core and third-party modules in order to do so...)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2011-01-12 19:55:17 Re: arrays as pl/perl input arguments [PATCH]
Previous Message Alvaro Herrera 2011-01-12 19:51:43 Re: arrays as pl/perl input arguments [PATCH]