Re: Error-safe user functions - Mailing list pgsql-hackers

On Tue, Dec 13, 2022 at 6:03 PM Amul Sul <sulamul@gmail.com> wrote:
>
> On Mon, Dec 12, 2022 at 12:00 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > Andrew Dunstan <andrew@dunslane.net> writes:
> > > Maybe as we work through the remaining input functions (there are about
> > > 60 core candidates left on my list) we should mark them with a comment
> > > if no adjustment is needed.
> >
> > I did a quick pass through them last night.  Assuming that we don't
> > need to touch the unimplemented input functions (eg for pseudotypes),
> > I count these core functions as still needing work:
> >
> > aclitemin
> > bit_in
> > box_in
> > bpcharin
> > byteain
> > cash_in
> > cidin
> > cidr_in
> > circle_in
> > inet_in
> > int2vectorin
> > jsonpath_in
> > line_in
> > lseg_in
> > macaddr8_in
> > macaddr_in
>
> Attaching patches changing these functions except bpcharin,
> byteain, jsonpath_in, and cidin. I am continuing work on the next
> items below:
>
> > multirange_in
> > namein
> > oidin
> > oidvectorin
> > path_in
> > pg_lsn_in
> > pg_snapshot_in
> > point_in
> > poly_in
> > range_in
> > regclassin
> > regcollationin
> > regconfigin
> > regdictionaryin
> > regnamespacein
> > regoperatorin
> > regoperin
> > regprocedurein
> > regprocin
> > regrolein
> > regtypein
> > tidin
> > tsqueryin
> > tsvectorin
> > uuid_in
> > varbit_in
> > varcharin
> > xid8in
> > xidin

Attaching a complete set of the patches changing function till this
except bpcharin, byteain jsonpath_in that Andrew is planning to look
in. I have skipped reg* functions.
multirange_in and range_in changes are a bit complicated and big --
planning to resume work on that and the rest of the items in the list
in the last week of this month, thanks.


> > xml_in
> >
> > and these contrib functions:
> >
> > hstore:
> > hstore_in
> > intarray:
> > bqarr_in
> > isn:
> > ean13_in
> > isbn_in
> > ismn_in
> > issn_in
> > upc_in
> > ltree:
> > ltree_in
> > lquery_in
> > ltxtq_in
> > seg:
> > seg_in
> >
> > Maybe we should have a conversation about which of these are
> > highest priority to get to a credible feature.  We clearly need
> > to fix the remaining SQL-spec types (varchar and bpchar, mainly).
> > At the other extreme, likely nobody would weep if we never fixed
> > int2vectorin, for instance.
> >
> > I'm a little concerned about the cost-benefit of fixing the reg* types.
> > The ones that accept type names actually use the core grammar to parse
> > those.  Now, we probably could fix the grammar to be non-throwing, but
> > it'd be very invasive and I'm not sure about the performance impact.
> > It might be best to content ourselves with soft reporting of lookup
> > failures, as opposed to syntax problems.
> >
>

Regards,
Amul