| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Jelte Fennema-Nio <me(at)jeltef(dot)nl>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Support a wildcard in backtrace_functions |
| Date: | 2024-04-19 18:08:26 |
| Message-ID: | 2179475.1713550106@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> There are some things that are pretty hard to change once we've
> released them. For example, if we had a function or operator and
> somebody embeds it in a view definition, removing or renaming it
> prevents people from upgrading. But GUCs are not as bad.
Really? Are we certain that nobody will put SETs of this GUC
into their applications, or even just activate it via ALTER DATABASE
SET? If they've done that, then a GUC change means dump/reload/upgrade
failure.
I've not been following this thread, so I don't have an opinion
about what the design ought to be. But if we still aren't settled
on it by now, I think the prudent thing is to revert the feature
out of v17 altogether, and try again in v18. When we're still
designing something after feature freeze, that is a good indication
that we are trying to ship something that's not ready for prime time.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2024-04-19 18:42:13 | Re: allow changing autovacuum_max_workers without restarting |
| Previous Message | Robert Haas | 2024-04-19 18:04:40 | Re: WIP Incremental JSON Parser |