Greetings, * Peter Eisentraut (peter.eisentr...@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
signature.asc
Description: PGP signature
