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

From Tom Lane
Subject Re: BUG #18989: Output of \sf does not match original source for E quoted strings (unlike \df+ used to)
Date
Msg-id 1402670.1752760724@sss.pgh.pa.us
Whole thread Raw
In response to BUG #18989: Output of \sf does not match original source for E quoted strings (unlike \df+ used to)  (PG Bug reporting form <noreply@postgresql.org>)
List pgsql-bugs
PG Bug reporting form <noreply@postgresql.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



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti
Next
From: Tom Lane
Date:
Subject: Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti