From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | tim(dot)colles(at)ed(dot)ac(dot)uk |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18989: Output of \sf does not match original source for E quoted strings (unlike \df+ used to) |
Date: | 2025-07-17 13:58:44 |
Message-ID: | 1402670.1752760724@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> testdb=# create function test() returns text language sql begin atomic
> select E'\x12' || 'Hello World' || E'\x12'; end;
> CREATE FUNCTION
> testdb=# \sf test
> CREATE OR REPLACE FUNCTION public.test()
> RETURNS text
> LANGUAGE sql
> BEGIN ATOMIC
> SELECT ((''::text || 'Hello World'::text) || ''::text);
> END
> Hence if the output of \sf is used as the source to make some amendment to
> the function the result could easily end up unintentionally different to the
> original.
[ shrug... ] I do not see a bug here. The control characters are
there; if your editor mangles them, that's your editor's fault.
There are a ton of related scenarios where you could fear that
non-ASCII characters might get mangled during query editing.
If we tried to prevent them all, we'd make the editing experience
less pleasant not more so.
Personally I'd probably write chr(12) instead of what you did here.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-07-17 15:00:56 | Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti |
Previous Message | Tom Lane | 2025-07-17 13:45:34 | Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti |