Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group