From: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
---|---|
To: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Michael Paquier <michael(at)paquier(dot)xyz>, Colin Watson <cjwatson(at)canonical(dot)com> |
Subject: | Re: Backport "WITH ... AS MATERIALIZED" syntax to <12? |
Date: | 2019-10-19 15:30:49 |
Message-ID: | 5a680a43-2d04-a1b1-7a97-6c4ebec311cb@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/19/19 11:10 AM, Isaac Morland wrote:
> On Sat, 19 Oct 2019 at 10:53, Andrew Dunstan
> <andrew(dot)dunstan(at)2ndquadrant(dot)com
> <mailto:andrew(dot)dunstan(at)2ndquadrant(dot)com>> wrote:
>
>
> > In general, I'm not opposed to accepting and ignoring the
> MATERIALIZED
> > syntax (assuming we'd only accept AS MATERIALIZED, but not the
> negative
> > variant).
> >
> > FWIW I'm not sure the "we don't want to upgrade application code
> at the
> > same time as the database" is really tenable.
>
> I'm -1 for exactly this reason.
>
> In any case, if you insist on using the same code with pre-12 and
> post-12 releases, this should be achievable (at least in most
> cases) by
> using the "offset 0" trick, shouldn't it?
>
>
> That embeds a temporary hack in the application code indefinitely.
>
> If only we had Guido's (Python) time machine. We could go back and
> start accepting "AS MATERIALIZED" as noise words starting from version
> 7 or something.
let me know when that's materialized :-)
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2019-10-19 15:31:25 | Re: SQL/JSON: JSON_TABLE |
Previous Message | Andrew Dunstan | 2019-10-19 15:26:50 | Re: jsonb_set() strictness considered harmful to data |