From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SELECT INTO deprecation |
Date: | 2020-12-02 16:14:11 |
Message-ID: | CAFj8pRBSirDotmvook8pkqV16Y6P3+2JtAhHD2okj9tvBEBePA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
st 2. 12. 2020 v 12:55 odesílatel Peter Eisentraut <
peter(dot)eisentraut(at)enterprisedb(dot)com> napsal:
> 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 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.
>
> 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.
>
+1
Pavel
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-12-02 16:18:18 | Re: Deprecate custom encoding conversions |
Previous Message | Heikki Linnakangas | 2020-12-02 16:04:11 | Deprecate custom encoding conversions |