Re: Error-safe user functions

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Joe Conway <mail(at)joeconway(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Error-safe user functions
Date: 2022-12-07 17:46:26
Message-ID: CAKFQuwYEBZw5UrPSa6U5=A+a82dagAYBfoZLYb4CuBxbE1vTmA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 7, 2022 at 10:34 AM Andres Freund <andres(at)anarazel(dot)de> wrote:

> > +{ oid => '8053',
> > + descr => 'get error message if string is not valid input for data
> type',
> > + proname => 'pg_input_invalid_message', provolatile => 's',
> > + prorettype => 'text', proargtypes => 'text regtype int4',
> > + prosrc => 'pg_input_invalid_message_mod' },
> > +
>
> Is there a guarantee that input functions are stable or immutable? We don't
> have any volatile input functions in core PG:
>
> SELECT provolatile, count(*) FROM pg_proc WHERE oid IN (SELECT typinput
> FROM pg_type) GROUP BY provolatile;
>
>
Effectively yes, though I'm not sure if it is formally documented or
otherwise enforced by the system.

The fact we allow stable is a bit of a sore spot, volatile would be a
terrible property for an I/O function.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-12-07 17:50:27 Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)
Previous Message Andres Freund 2022-12-07 17:44:39 Re: [PATCH] pg_dump: lock tables in batches