Re: Identifying no-op length coercions - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Identifying no-op length coercions
Date
Msg-id BANLkTimh8hgYHWNeMou_xj1Yhd17o1NN0Q@mail.gmail.com
Whole thread Raw
In response to Re: Identifying no-op length coercions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Identifying no-op length coercions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, May 23, 2011 at 12:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>  Given that the helper function is going to have a
> signature along the lines of "(internal, internal) -> internal", it's
> going to be difficult for anyone to use it for non-builtin functions
> anyhow.

I hate to go around in circles on this but I didn't see the original discussion.

This was the thing that concerned me. If anyone wants to add this
feature for a new data type they're going to have to understand and
tie their code to all this internal parser node stuff. That means
their code will be much more closely tied to a specific version, will
have to be written in C, and will require much more in-depth
understanding of Postgres internal data structures.

By comparison the boolean cast predicate could be written in any
language and only required the data type implementor to understand
their data type. It seems much more likely to actually get used and be
used correctly.



--
greg


pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: WIP: collect frequency statistics for arrays
Next
From: "Kevin Grittner"
Date:
Subject: Re: SSI predicate locking on heap -- tuple or row?