pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Nikita Glukhov <n.gluhov@postgrespro.ru>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Jonathan S. Katz <jkatz@postgresql.org>
Cc: Amit Langote <amitlangote09@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: John Naylor <john.naylor@enterprisedb.com>
Subject: Re: SQL/JSON features for v15
Date: Thu, 29 Sep 2022 23:28:55 -0400
Message-ID: <522209.1664508535@sss.pgh.pa.us> (raw)
In-Reply-To: <d29e076b-d7b8-9bb1-4eef-d4e22d7ff1c2@dunslane.net>
References: <CA+HiwqH8gTp2uNN3QtgeOSgHhZUZz1=0U+JObJJUmEoch_269Q@mail.gmail.com>
	<20220830092008.6dbublx6la226zis@alvherre.pgsql>
	<CA+HiwqFvP23i3kTHt6TW4FqO6he1YSJXeyGOdFV_YbP=xeS99A@mail.gmail.com>
	<f54ebd2b-0e67-d1c6-4ff7-5d732492d1a0@postgrespro.ru>
	<CA+HiwqHLVPdA7e3Y-S5giKPsqQPf8M0nuvgz8+3D8GjQexXLYA@mail.gmail.com>
	<CA+HiwqECHA0aUi0Bo3tdYTJ27i2MRWUZ5BewQoO0WgRvRXQO-Q@mail.gmail.com>
	<abd31e0b-56aa-044f-6700-8a1c1bba87f1@dunslane.net>
	<2276d20d-43ff-f9f6-5c9c-c2875739e66c@postgresql.org>
	<20220831154916.pgspuz3bp4427int@awork3.anarazel.de>
	<4151123.1661961884@sss.pgh.pa.us>
	<13351.1661965592@sss.pgh.pa.us>
	<CA+TgmobX2330ByUrrSo1SbcoRPYBbZ1bp3h54hLsxsd1AeBocQ@mail.gmail.com>
	<14814.1661966096@sss.pgh.pa.us>
	<379e5365-9670-e0de-ee08-57ba61cbc976@postgrespro.ru>
	<0574201c-bd35-01af-1557-8936f99ce5aa@postgrespro.ru>
	<d29e076b-d7b8-9bb1-4eef-d4e22d7ff1c2@dunslane.net>

Andrew Dunstan <andrew@dunslane.net> writes:
> I suggest just submitting the Input function stuff on its own, I think
> that means not patches 3,4,15 at this stage. Maybe we would also need a
> small test module to call the functions, or at least some of them.
> The earlier we can get this in the earlier SQL/JSON patches based on it
> can be considered.

+1

> . proissafe isn't really a very informative name. Safe for what? maybe
> proerrorsafe or something would be better?

I strongly recommend against having a new pg_proc column at all.
I doubt that you really need it, and having one will create
enormous mechanical burdens to making the conversion.  (For example,
needing a catversion bump every time we convert one more function,
or an extension version bump to convert extensions.)

			regards, tom lane





view thread (95+ messages)

Message-ID: <522209.1664508535@sss.pgh.pa.us>
Permalink:  ../522209.1664508535@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/522209.1664508535@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, andrew@dunslane.net, n.gluhov@postgrespro.ru, robertmhaas@gmail.com, andres@anarazel.de, jkatz@postgresql.org, amitlangote09@gmail.com, alvherre@alvh.no-ip.org, pgsql-hackers@lists.postgresql.org, michael@paquier.xyz, john.naylor@enterprisedb.com
  Subject: Re: SQL/JSON features for v15
  In-Reply-To: <522209.1664508535@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox