Re: [PATCH] plpythonu datatype conversion improvements - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] plpythonu datatype conversion improvements
Date
Msg-id 503.1250520169@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] plpythonu datatype conversion improvements  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: [PATCH] plpythonu datatype conversion improvements  (Andrew Dunstan <andrew@dunslane.net>)
Re: [PATCH] plpythonu datatype conversion improvements  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> The remaining problem is that the patch loses domain checking on the
> return types, because some paths no longer go through the data type's
> input function.  I have marked these places as FIXME, and the regression
> tests also contain a failing test case for this.

For the record, I think this entire patch is a bad idea.  PLs should not
be so much in bed with the internal representation of datatypes.  To
take just one example, this *will* break when/if we change text to carry
some internal locale indicator.  There has been absolutely zero evidence
presented to justify that there's a need to break abstraction to gain
performance in this area.

> What's needed here, I think, is an API that takes a datum plus type
> information and checks whether the datum is valid within the domain.  I
> haven't found one that is exported, but maybe someone could give a tip.

There isn't one, but maybe you could expose domain_state_setup and
domain_check_input, or some simple wrapper around them.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: freezing tuples ( was: Why is vacuum_freeze_min_age100m? )
Next
From: Andrew Dunstan
Date:
Subject: Re: [PATCH] plpythonu datatype conversion improvements