Re: BUG #18989: Output of \sf does not match original source for E quoted strings (unlike \df+ used to)

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

In response to

Browse pgsql-bugs by date

  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