On Wed, Jan 12, 2011 at 2:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Jan 12, 2011 at 2:35 PM, Tom Lane <tgl@sss.pgh.pa.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...)
In terms of solving the immediate problem, you're probably correct.
But this isn't the first time this issue has come up, and it probably
won't be the last. It's pretty lame to waste 4+ bytes on disk for
every value of a given type due to a parameter-passing convention.
And I suppose it's worth pointing out that if Jeff does adopt that
solution, we'll be stuck with it for approximately forever due to
pg_upgrade.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
