Re: Unescaped new lines in postgres

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Unescaped new lines in postgres
Date: 2001-11-23 16:23:30
Message-ID: 6214.1006532610@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
>> From heap.c:
> /*
> * sanity checks
> */
> if (relname && !allow_system_table_mods &&
> IsSystemRelationName(relname) && IsNormalProcessingMode())
> elog(ERROR, "invalid relation name \"%s\"; "
> "the 'pg_' name prefix is reserved for system
> catalogs",
> relname);

> I guess this is a slightly different example than what the issue is below.
> Maybe I'm wrong and the above code is still legal.

This is legal ANSI C. The spec says that one of the later phases of the
preprocessor is

6. Adjacent string literal tokens are concatenated.

I have an old book on C portability that says that this behavior
actually predates the ANSI spec, but wasn't universal in pre-ANSI
compilers.

It's also legal per spec to write

"invalid relation name \"%s\"; \
the 'pg_' name prefix is reserved for system catalogs",

(note the backslash before the newline) but this strikes me as worse
style since you now have a critical dependency on (a) lack of trailing
whitespace on the first line and (b) lack of leading whitespace on the
second.

What the gcc release note is about is

"invalid relation name \"%s\";
the 'pg_' name prefix is reserved for system catalogs",

Unescaped newlines in string literals are specifically forbidden by
the spec, but apparently gcc takes them anyway.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Buttafuoco 2001-11-23 16:28:49 Re: postgresql.conf (Proposed settings)
Previous Message Hannu Krosing 2001-11-23 16:12:53 Re: OCTET_LENGTH is wrong