| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, adam(at)labkey(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails |
| Date: | 2024-12-03 01:41:01 |
| Message-ID: | 1710259.1733190061@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Mon, Dec 2, 2024 at 06:16:19PM -0500, Tom Lane wrote:
>> Reality is that using multiple encodings in shared catalogs just plain
>> doesn't work very well. Even something as simple as "select datname
>> from pg_database" is likely to give garbage if there are entries in
>> encodings that don't match your current database's encoding. What
>> Thomas is proposing is to formalize and then enforce the two usage
>> patterns that we know work okay.
> I have not heard of anyone complaining about the problem of viewing the
> shared catalog columns so I didn't consider that benefit.
That's probably because they've learned the hard way to use one of
the two usage patterns that actually work.
Also, I think we have some code around pg_stat_activity that
suppresses possibly-wrongly-encoded data from other DBs (in query
text, not only user/DB names). That suppression could be relaxed
in the only-one-encoding mode, which would be a genuinue benefit.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sandeep Thakkar | 2024-12-03 06:03:20 | Re: BUG #18707: Installation issue |
| Previous Message | PG Bug reporting form | 2024-12-03 01:31:44 | BUG #18730: Inequality comparison operators and SMALLINT negative immediate value |