Date: Wed, 2 Dec 2020 12:58:36 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: SELECT INTO deprecation
Message-ID: <20201202175836.GX16415@tamriel.snowman.net>
References: <96dc0df3-e13a-a85d-d045-d6e2c85218da@enterprisedb.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="y7PNzQCyfOEoXXT7"
Content-Disposition: inline
In-Reply-To: <96dc0df3-e13a-a85d-d045-d6e2c85218da@enterprisedb.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--y7PNzQCyfOEoXXT7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Greetings,

* Peter Eisentraut (peter.eisentraut@enterprisedb.com) wrote:
> While reading about deprecating and removing various things in other
> threads, I was wondering about how deprecated SELECT INTO is.  There are
> various source code comments about this, but the SELECT INTO reference page
> only contains soft language like "recommended".  I'm proposing the attached
> patch to stick a more explicit deprecation notice right at the top.

I don't see much value in this.  Users already have 5 years to adapt
their code to new major versions of PG and that strikes me as plenty
enough time and is why we support multiple major versions of PG for so
long.  Users who keep pace and update for each major version aren't
likely to have issue making this change since they're already used to
regularly updating their code for new major versions, while others are
going to complain no matter when we remove it and will ignore any
deprecation notices we put out there, so there isn't much point in them.

> I also found some gratuitous uses of SELECT INTO in various tests and
> documentation (not ecpg or plpgsql of course).  Here is a patch to adjust
> those to CREATE TABLE AS.

If we aren't actually removing SELECT INTO then I don't know that it
makes sense to just stop testing it.

> I don't have a specific plan for removing top-level SELECT INTO altogether,
> but there is a nontrivial amount of code for handling it, so there would be
> some gain if it could be removed eventually.

We should either remove it, or remove the comments that it's deprecated,
not try to make it more deprecated or try to somehow increase the
recommendation to not use it.

I'd recommend we remove it and make note that it's been removed in v14
in the back branches at the same time, which will give those who
actually pay attention and care that much more time before v14 comes out
to update their code (not that I'm all that worried, as they'll also see
it in the beta release notes too).

Thanks,

Stephen

--y7PNzQCyfOEoXXT7
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJfx9XLAAoJEO1sijiDR2RVNG0P/1jN4lQBlFZnasloveyyzQC8
PiP9bVpFUa7i741O5+5qj602bf1tXeD1uvY8R3Xa2ZDuk2E8AgQzvOXEUzm5TyIw
pMOhMzMIVGKG4o4BzA1ZC/QtVU0F8sZFTJBVv19qjtR7c30Vfcpa1dkZRQURu5cX
82yximVMdXCsqjuX6sQ6ZgDAjk/2WL+2GpEukudU9NPOoheMvCCQkLp3IYsfYHlw
NU74s0wV4BSv0tCl7tBC6xLCV09frAZZP+KvIv5raQqxJ5PZTNsm0PhqjIshcQ4h
4Shz4Aqa6DTPM0cTVQMwku5Ksweu1YEwgc4NXexnO0S5TMMDRMZxW6X64WlHyU7K
OFqHS2XFzFjVNBf5ewR56YcAgI2JQP9F6WupTPQBSC7AF1VXmNtPqK5HKCJaut2E
UuchB8phOSL0D1sWa17NjGZGDVaABZ/te3uiNkJqE5MTfGU/nFbDyBFhzJZyxPXZ
sdNVBVqSS/2+EREZ0gWG7v2O/sVgT1ax9dpj+lJPgFQdw6NxBmGhACsOBIEzIG3j
t+4Sh9WJm3kQRkYrJruTN+rkCjzg99qX3uCS+qcLBKjKwgiCbsvRfcDjV4J5/whN
JVHA0tyy+k3DQxBkyau9a6jhpu6S9rHf5l5oJJ53WUDz/3W76c3/eLg5GDR2vrGZ
iVrKeq+qXMqypWW+arG2
=zNz8
-----END PGP SIGNATURE-----

--y7PNzQCyfOEoXXT7--