From: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
---|---|
To: | Serge Rielau <serge(at)rielau(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Doug Doole <ddoole(at)salesforce(dot)com> |
Subject: | Re: Cached plans and statement generalization |
Date: | 2017-04-25 20:37:37 |
Message-ID: | 58FFB391.5080101@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 04/25/2017 08:09 PM, Serge Rielau wrote:
>
> On Tue, Apr 25, 2017 at 9:45 AM, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> wrote:
>
> On 25.04.2017 19:12, Serge Rielau wrote:
>
>
> On Apr 25, 2017, at 8:11 AM, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru <mailto:k(dot)knizhnik(at)postgrespro(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Serge Rielau | 2017-04-25 20:40:10 | Re: Cached plans and statement generalization |
Previous Message | Konstantin Knizhnik | 2017-04-25 20:35:21 | Re: Cached plans and statement generalization |