| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Add more information_schema columns |
| Date: | 2018-02-13 23:39:47 |
| Message-ID: | 6614.1518565187@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> Do we have a policy about catversion bumps for information schema
> changes? A cluster from before this commit fails the regression tests
> after the change, but still mostly works...
I think historically we've not bumped catversion, on the grounds that
there's no incompatibility with the backend as such. However, it is
kind of annoying that not updating means the regression tests fail.
Informally, I'm sure most developers take "catversion bump" to mean
"you need to initdb". So I'd support saying that an information_schema
change should include a catversion bump if it involves any changes in
regression test results.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2018-02-14 00:43:41 | Re: master plpython check fails on Solaris 10 |
| Previous Message | Nikita Glukhov | 2018-02-13 23:09:12 | Re: SQL/JSON: JSON_TABLE |