Re: quoting psql varible as identifier

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: quoting psql varible as identifier
Date: 2010-01-02 18:10:23
Message-ID: 162867791001021010l58b3d7ebjc7dc5dd0fb5f310e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2009/12/30 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Tue, Dec 29, 2009 at 3:19 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> here is patch
>
> The error handling in quote_literal() doesn't look right to me.  The
> documentation for PQescapeStringConn says that it stores an error
> message in the conn object, but your code ignores that and prints out
> a generic message instead.  That doesn't seem right: but then it
> further goes on to call exit(1), which seems like a considerable
> overreaction to an encoding violation, which is apparently the only
> class of error PQescapeStringConn() is documented to throw.

Actually I am not sure about the adequate solution. Now, the lexer
doesn't return any error. Any handled errors are fatal, and lexer (and
psql) is finished with exit(1) - so there are not checking status
after any lexer call. It is question if we have to do it. Because
error will be raised in next stage:

"Presently the only possible error conditions involve invalid
multibyte encoding in the source string. The output string is still
generated on error, but it can be expected that the server will reject
it as malformed. On error, a suitable message is stored in the conn
object, whether or not error is NULL."

http://www.postgresql.org/docs/8.4/static/libpq-exec.html#LIBPQ-EXEC-ESCAPE-STRING

so probably - we can quietly ignore this error without security or
functionality issues.

I see two solution:

a) print correct message and exit(1)
b) quietly ignore this error - it's more warning than error, because
error will be raised immediately

Third variant, checking lexer status over every call is maybe non
adequate to frequency of this error and an importance of this patch. I
am for a.

Regards, and happy new year
Pavel

>
> ...Robert
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrus 2010-01-02 18:14:07 FM format modifier does not remove leading zero from year
Previous Message Tom Lane 2010-01-02 16:09:06 Re: pgsql: Fix one more cast for _open_osfhandle().