Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d340W-0005dq-6d for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Apr 2017 17:12:08 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1d340V-0001zX-Kt for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Apr 2017 17:12:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d33yz-00077G-Qb for pgsql-hackers@postgresql.org; Tue, 25 Apr 2017 17:10:33 +0000 Received: from p3plsmtpa09-06.prod.phx3.secureserver.net ([173.201.193.235]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d33yw-000211-0S for pgsql-hackers@postgresql.org; Tue, 25 Apr 2017 17:10:32 +0000 Received: from [54.210.254.254] ([54.210.254.254]) by :SMTPAUTH: with SMTP id 33yMdLBDA6KTr33yNd6nLW; Tue, 25 Apr 2017 10:09:55 -0700 Content-Type: multipart/alternative; boundary="----sinikael-?=_1-14931401950840.5582595171872526" From: Serge Rielau To: Konstantin Knizhnik Cc: Pg Hackers , Doug Doole In-Reply-To: <1f4c1a22-ecbe-811d-4695-ee4701b8f6c7@postgrespro.ru> References: <8e76d8fc-8b8c-14bd-d4d1-e9cf193a74f5@postgrespro.ru> <20170424184353.u2krt2eiw2l6e2af@alap3.anarazel.de> <1f4c1a22-ecbe-811d-4695-ee4701b8f6c7@postgrespro.ru> Subject: Re: Cached plans and statement generalization Message-Id: Date: Tue, 25 Apr 2017 10:09:37 -0700 X-Cm-Message-Id: 149314017795794942d44f8586ac520bd026de8f2887260c58ff82d1e9eab377967361 X-Cm-Draft-Id: WyJhIiwzLCJkcmFmdF9pZCIsIjE0OTMxNDAxNzc1OTUiLCJ2IiwxXQ== X-Cm-Tracking-Code: 2.0/1493140177/647b813270dffd4c4b2631f3c9eb3f46/3/9cf3801d03770ada01bb39dc8f52321d/775289bb3896a53f4abc2a201238b024/619f5dd6cf0c728abb479c46d4dbfbe4 X-Mailer: Newton MIME-Version: 1.0 X-CMAE-Envelope: MS4wfJwD6PS/rreXOT3y8z3GTj7cTtrhqrfHwSMw36/Nkxw2LZ0ZAbNKi8IV8vDMln2QTNvkczP1OusBXpQ3gpy9m85UMPLJYDTjMKB4AGIskTgG+jCmjqJp B8tK6A5VUG0nzNJ8epUCrRjMaWlEYFh4cvHChxL1862b50BTcs94wwk7OpeCcTiWhe5EPptfbMDcdA== X-Pg-Spam-Score: -0.3 (/) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org ------sinikael-?=_1-14931401950840.5582595171872526 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 25, 2017 at 9:45 AM, Konstantin Knizhnik wrote: On 25.04.2017 19:12, Serge Rielau wrote: On Apr 25, 2017, at 8:11 AM, Konstantin Knizhnik < k.knizhnik@postgrespro.= ru [k.knizhnik@postgrespro.ru] > wrote: Another problem is caused by using = integer literals in context where parameters can not be used, for example = "order by 1=E2=80=9D. You will also need to deal with modifiers in types = such as VARCHAR(10). Not sure if there are specific functions which can = only deal with literals (?) as well. Sorry, I do not completely understand = how presence of type modifiers can affect string literals used in query. Can you provide me some example? SELECT =E2=80=98hello=E2=80=99::CHAR(10) = || =E2=80=98World=E2=80=99, 5 + 6; You can substitute = =E2=80=98hello=E2=80=99, =E2=80=98World=E2=80=99, 5, and 6. But not 10. Also some OLAP syntax like =E2=80=9Crows preceding=E2=80=9D It pretty much boils down to whether you can do some shallow parsing rather= than expending the effort to build the parse tree. Cheers Serge ------sinikael-?=_1-14931401950840.5582595171872526 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On = Tue, Apr 25, 2017 at 9:45 AM, Konstantin Knizhnik <k.= knizhnik@postgrespro.ru> wrote:
On 25.04.2017 19:12, Serge Rielau wrote:
=20
On = Apr 25, 2017, at 8:11 AM, Konstantin Knizhnik <k.knizhnik@postgrespro= .ru> wrote:
Another problem is caused by = using integer literals in context where parameters can not be= used, for example "order by 1=E2=80=9D.
You will also need to deal with modifiers in types such as VARCHAR(10). Not sure if there are specific functions which can only deal with literals (?) as well.
Sorry, I do not completely understand how presence of type modifiers can affect string literals used in query.
Can you provide me = some example?
SELECT = =E2=80=98hello=E2=80=99::CHAR(10) || =E2=80=98World=E2=80=99, 5 + = 6;

You can substitute =E2=80=98hello=E2=80=99, = =E2=80=98World=E2=80=99, 5, and 6. But not 10.

Also some = OLAP syntax like =E2=80=9Crows preceding=E2=80=9D

It pretty = much boils down to whether you can do some shallow parsing rather than = expending the effort to build the parse tree.

Cheers
=
Serge
------sinikael-?=_1-14931401950840.5582595171872526--