Re: making the backend's json parser work in frontend code

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Steele <david(at)pgmasters(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: making the backend's json parser work in frontend code
Date: 2020-01-24 15:05:27
Message-ID: ab359258-6268-773e-046d-1ca3b5d83afe@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-01-23 18:04, Robert Haas wrote:
> Now, you might say "well, why don't we just do an encoding
> conversion?", but we can't. When the filesystem tells us what the file
> names are, it does not tell us what encoding the person who created
> those files had in mind. We don't know that they had*any* encoding in
> mind. IIUC, a file in the data directory can have a name that consists
> of any sequence of bytes whatsoever, so long as it doesn't contain
> prohibited characters like a path separator or \0 byte. But only some
> of those possible octet sequences can be stored in a manifest that has
> to be valid UTF-8.

I think it wouldn't be unreasonable to require that file names in the
database directory be consistently encoded (as defined by pg_control,
probably). After all, this information is sometimes also shown in
system views, so it's already difficult to process total junk. In
practice, this shouldn't be an onerous requirement.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-01-24 15:20:30 Re: Allow to_date() and to_timestamp() to accept localized names
Previous Message Amit Langote 2020-01-24 14:44:34 Re: progress report for ANALYZE