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

From Tom Lane
Subject Re: Identifying no-op length coercions
Date
Msg-id 20501.1306183266@sss.pgh.pa.us
Whole thread Raw
In response to Re: Identifying no-op length coercions  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> 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.

I don't think I believe that interesting length-conversion functions are
going to be written in anything but C anyway, so I don't find that that
argument holds much water.  Generally, the low-level functions for a new
datatype have to be in C.

As for the other point, if all you want to do is examine the
expression's typmod, the API for that is pretty stable (exprTypmod()).
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: SSI predicate locking on heap -- tuple or row?
Next
From: Noah Misch
Date:
Subject: Re: Identifying no-op length coercions