From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Денис Романенко <deromanenko(at)gmail(dot)com>, Alvaro Herrera from 2ndQuadrant <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: NAMEDATALEN increase because of non-latin languages |
Date: | 2021-08-18 17:12:13 |
Message-ID: | CAOBaU_bc32L0zJdm3+pMjDtALE-FQaesj6zkYEG7MkFg=n_7kw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Aug 19, 2021 at 12:12 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Yeah, exactly: conceptually that's simple, but flushing all the bugs
> out would be a years-long nightmare. It'd make all the fun we had
> with missed attisdropped checks look like a walk in the park. Unless
> somebody can figure out a way to mechanically check for mistakes,
> I don't think I want to go there.
Maybe a silly idea, but we could have some shared_preload_libraries
module with a command_utility_hook that intercept table creation and
randomize the logical column order. If we also have some GUC (assert
only if needed) to switch star expansion to physical-order rather than
logical-order, we could then use the regression test as a big hammer
to see if anything breaks. That's clearly not ideal (it would
obviously need some other hacks to avoid other breakage like \d and
other things) and not 100% coverage, but it should give some
confidence in any patch completeness.
From | Date | Subject | |
---|---|---|---|
Next Message | Bossart, Nathan | 2021-08-18 17:24:38 | Re: archive status ".ready" files may be created too early |
Previous Message | Bossart, Nathan | 2021-08-18 17:09:44 | pg_dump handling of ALTER DEFAULT PRIVILEGES IN SCHEMA |