On Tue, Jul 02, 2024 at 01:46:21PM +0300, Aleksander Alekseev wrote: > I can imagine how this may impact many applications and upset many > software developers worldwide. Was there even a precedent (in the > recent decade or so) when PostgreSQL broke the SQL syntax?
We're usually very careful about that, and maintaining a backward-compatible grammar has a minimal cost in the parser. The closest thing I can think of that has a rather complicated grammar is COPY, which has *two* legacy grammars still supported, one for ~7.3 and one for ~9.0. > To clarify, I'm not opposed to this idea. If we are fine with breaking > backward compatibility on the SQL level, this would allow dropping the > support of inherited tables some day, a feature that in my humble > opinion shouldn't exist (I realize this is another and very debatable > question though). I just don't think this is something we ever do in > this project. But I admit that this information may be incorrect > and/or outdated. I am not sure that there is much to gain with this proposal knowing that the commands with matviews have been around for quite a long time now. Particularly, after looking at 0001, you'd see that it shortcuts a couple of areas of the CTAS code because that's what we are relying on when building the initial data of matviews. Hence, implementation-wise in the backend, matviews are much closer to physical relations than views. This is trying to make matviews behave more consistently with views. This topic has been mentioned once on pgsql-general back in 2019, for reference: https://www.postgresql.org/message-id/CAAWhf%3DPHch2H3ekYnbafuwqWqwyRok8WVPaDxKosZE4GQ2pq5w%40mail.gmail.com -- Michael
signature.asc
Description: PGP signature
