From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: function parse_ident |
Date: | 2016-03-14 16:39:29 |
Message-ID: | 56E6E941.7030507@sigaev.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I afraid so I cannot to fix this inconsistency (if this is inconsistency - the
> binary values are same) - the parameter of function is raw string with processed
> escape codes, and I have not any information about original escape sequences.
> When you enter octet value, and I show it as hex value, then there should be
> difference. Buy I have not information about your input (octet or hex). I have
> the original string of SQL identifier inside parser, executor, but I have not
> original string of function parameter inside function (not without pretty
> complex and long code).
Ok, agree
>
> I am trying describe it in doc (I am sorry for my less level English) in new
> patch. Fixed duplicated oid too.
Edited a bit + fix some typos and remove unneeded headers, patch attached
Sorry, I can't find all corner-cases at once, but:
SELECT parse_ident(E'"c".X XXXXXXXXXX');
ERROR: identifier contains disallowed characters: "\"c"
Error message wrongly points to the reason of error.
--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
Attachment | Content-Type | Size |
---|---|---|
parse_ident-13.patch | binary/octet-stream | 14.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2016-03-14 16:40:57 | Re: [COMMITTERS] pgsql: Refactor to create generic WAL page read callback |
Previous Message | Tom Lane | 2016-03-14 16:30:33 | Re: [PATCH] Use correct types and limits for PL/Perl SPI query results |