Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d37F4-0004Kk-8a for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Apr 2017 20:39:22 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1d37F3-0007K2-LQ for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Apr 2017 20:39:21 +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 1d37DX-0004h4-Jf for pgsql-hackers@postgresql.org; Tue, 25 Apr 2017 20:37:47 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by magus.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d37DP-0006gl-BT for pgsql-hackers@postgresql.org; Tue, 25 Apr 2017 20:37:47 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 45B7E21C2983; Tue, 25 Apr 2017 23:37:38 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru Message-ID: <58FFB391.5080101@postgrespro.ru> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1493152658; bh=zKO+pdrXdK+h+lBVFHXdfChxyBE8QAzG8BrC39zJr6s=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=FiYtmF/xIauEmm0rEZlXkbxWS7zdAmeHTA2C4+5h0RMGYji8oUU+cgRv0FHFdW/YS WlBrT48sEzvCr47ZxAlNnb2uUi+gF8lid+sACWMORnfVKpLv9awOKP+aoIx6JmLN5K MZGfKyr851mBWi1hP8H/3/7wxnGEfc/YNS0RCFqQ= Date: Tue, 25 Apr 2017 23:37:37 +0300 From: Konstantin Knizhnik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Serge Rielau CC: Pg Hackers , Doug Doole Subject: Re: Cached plans and statement generalization References: <8e76d8fc-8b8c-14bd-d4d1-e9cf193a74f5@postgrespro.ru> <20170424184353.u2krt2eiw2l6e2af@alap3.anarazel.de> <1f4c1a22-ecbe-811d-4695-ee4701b8f6c7@postgrespro.ru> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090602010909000700070406" X-Pg-Spam-Score: -2.0 (--) 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 This is a multi-part message in MIME format. --------------090602010909000700070406 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 04/25/2017 08:09 PM, Serge Rielau wrote: > > 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 > wrote: > Another problem is caused by using integer literals in context where parameters can not be used, for example "order by 1”. > > 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 ‘hello’::CHAR(10) || ‘World’, 5 + 6; > > You can substitute ‘hello’, ‘World’, 5, and 6. But not 10. I am substituting only string literals. So the query above will be transformed to SELECT $1::CHAR(10) || $2, 5 + 6; What's wrong with it? > > Also some OLAP syntax like “rows preceding” > > 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 -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company --------------090602010909000700070406 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 04/25/2017 08:09 PM, Serge Rielau wrote:

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:

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”.
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 ‘hello’::CHAR(10) || ‘World’, 5 + 6;

You can substitute ‘hello’, ‘World’, 5, and 6. But not 10.

I am substituting only string literals. So the query above will be transformed to

SELECT $1::CHAR(10) || $2, 5 + 6;

What's wrong with it?


Also some OLAP syntax like “rows preceding”

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


-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--------------090602010909000700070406--