Re: NAMEDATALEN increase because of non-latin languages

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.

In response to

Browse pgsql-hackers by date

  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