| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Mahendra Singh Thalor <mahi6run(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, Srinath Reddy <srinath2133(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Non-text mode for pg_dumpall |
| Date: | 2025-03-11 22:37:14 |
| Message-ID: | a84a3e28-7517-4e5c-8049-395816278c81@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2025-03-11 Tu 5:03 PM, Álvaro Herrera wrote:
> On 2025-Mar-11, Andrew Dunstan wrote:
>
>> I'm not sure everyone thinks that was a good idea for backup manifests (in
>> fact I know some don't), and it seems somewhat like overkill for a simple
>> map of oids to database names.
> If such a simple system can be made to work for all possible valid
> database names, then I agree with you. But if it forces us to restrict
> database names to not contain newlines or other funny chars that are so
> far unrestricted, then I would take the other position.
>
Well, JSON is supposed to be UTF8. What should we do about database
names that are not UTF8?
It's kinda tempting to say we should have the file consist of lines like:
oid base64_encoded_name escaped_human_readable name
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2025-03-11 22:38:34 | Re: Statistics import and export: difference in statistics of materialized view dumped |
| Previous Message | Sami Imseih | 2025-03-11 22:35:10 | Re: Query ID Calculation Fix for DISTINCT / ORDER BY and LIMIT / OFFSET |