| 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: | Whole Thread | Raw Message | 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 |