Re: pg14 psql broke \d datname.nspname.relname
От | Mark Dilger |
---|---|
Тема | Re: pg14 psql broke \d datname.nspname.relname |
Дата | |
Msg-id | 2F3734AB-5E1C-40F8-9E4B-DDDB108FAF25@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: pg14 psql broke \d datname.nspname.relname (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: pg14 psql broke \d datname.nspname.relname
Re: pg14 psql broke \d datname.nspname.relname |
Список | pgsql-hackers |
> On Oct 12, 2021, at 10:03 AM, Robert Haas <robertmhaas@gmail.com> wrote: > > On Tue, Oct 12, 2021 at 12:57 PM Justin Pryzby <pryzby@telsasoft.com> wrote: >> I think there's an easy answer here that would satisfy everyone; two patches: >> 0001 to fix the unintentional behavior change; >> 0002 to reject garbage input: anything with more than 3 dot-separated >> components, or with 3 components where the first doesn't match >> current_database. >> >> 0001 would be backpatched to v14. >> >> If it turns out there's no consensus on 0002, or if it were really hard for >> some reason, or (more likely) nobody went to the bother to implement it this >> year, then that's okay. > > This might work, but I fear that 0001 would end up being substantially > more complicated than a combined patch that solves both problems > together. Here is a WIP patch that restores the old behavior, just so you can eyeball how large it is. (It passes check-world andI've read it over once, but I'm not ready to stand by this as correct quite yet.) I need to add a regression test tomake sure this behavior is not accidentally changed in the future, and will repost after doing so. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: