Is it ok to insert ascii decimal characters in postgres select query? - sql

Question

I need o/p of select statement in this way.
You are assigned to following projects:
A
B
C
There are some spaces, special characters & new lines. To do that I used ascii charaters chr(10), chr(32), chr(8226).
It's working fine but query doesn't look good & I am not sure if it's a good approach to do it like this.
The query looks like this
SELECT
'You are assigned to following projects:' || chr(10) || chr(32) || chr(8226) || chr(32) ||
string_agg(e.projects, chr(10) || chr(32) || chr(8226) || chr(32))
Also will this work in all OS & in every environment?

Answer 1

You have a few options:
Insert characters literally. Usually the best option. Want a "•"? Use a string like 'this is a •'. Nothing more is required if your client_encoding is correct and the encoding you're using includes the character you want (like •). This is SQL-standard. Newlines may be included as literals:
SELECT '
' AS "this_is_a_newline";
This approach may not work for some non-printable characters, depending on the database implementation. For PostgreSQL it's fine for everything except \x00, the zero byte, which PostgreSQL doesn't support in text / varchar etc at all, only in bytea.
Watch out to make sure your text editor / SQL editor's text encoding matches what your connection tells PostgreSQL the client_encoding is, otherwise you'll get mangled strings or weird errors. Users of unix-like terminals also need to make sure the terminal encoding matches client_encoding to avoid weird output errors. These days Windows is the only platform where this is generally an issue.
Insert characters by hex or unicode literal in an E'' escape-string, e.g. E'this is a \u2022' . Note that \u escapes are hexadecimal - 0x2022 is decimal 8226. The E'' syntax is a PostgreSQL extension.
For characters that have shorthand escapes defined, use the shorthand escapes in an escape-string, e.g. E'\n'. This is a PostgreSQL extension.
use chr(8226), as you described, but note that chr interprets the code according to your server_encoding (the database's text encoding). So I do not encourage it. For multi-byte chars you'll just get an error like ERROR: requested character too large for encoding: 8226:
regress=> CREATE DATABASE latin ENCODING 'latin-1' LC_CTYPE 'C' LC_COLLATE 'C' TEMPLATE template0;
CREATE DATABASE
regress=> \c latin
You are now connected to database "latin" as user "craig".
latin=> SHOW server_encoding;
server_encoding
-----------------
LATIN1
(1 row)
latin=> SHOW client_encoding;
client_encoding
-----------------
UTF8
(1 row)
latin=> select chr(8226);
ERROR: requested character too large for encoding: 8226
but for chars whose ordinal is in the 1-byte range, you can get an unexpected character instead. Take ü, which in both utf-8 and latin-1 (iso-8859-1) is 0xfc (decimal 252), but in iso-8859-5 is ќ. So:
regress=> SHOW server_encoding;
server_encoding
-----------------
UTF8
regress=> SELECT chr(252);
chr
-----
ü
regress=> CREATE DATABASE iso5 ENCODING 'iso-8859-5' LC_CTYPE 'C' LC_COLLATE 'C' TEMPLATE template0;
regress=> \c iso5
iso5=> SELECT chr(252);
chr
-----
ќ
So my advice: Always use literals where possible. Where you must use escapes, use E'' strings with unicode escapes to prevent ambiguity about the meaning of a codepoint based on the current server encoding. Avoid \x escapes and chr.
For the specific example you wrote, you should use:
SELECT 'You are assigned to following projects:
• A
• B
• C';
Note for readers on very old PostgreSQL versions: Extremely old PostgreSQL release didn't support E'' strings and treated all strings as if they were escape strings. So '\n' meant "newline" whereras modern PostgreSQL follows the SQL standard in which '\n' is just the string "\n". Only marginally prehistoric versions still did this, but raised a warning about it and let you request the standard behaviour by setting standard_conforming_strings = on. This has been the default for quite a while.

Answer 2

Instead of
chr(10) || chr(32) || chr(8226) || chr(32)
just use
\n •
No reason to use chr() in this case.