On 2020-01-02 14:26, Pavel Stehule wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
This patch replaced query str
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
This patch replaced query string by parse state on few places. It increas
After digesting the discussion, let's reshuffle this a bit.
I have committed the change that adds the error location in one place.
That worked independently.
Attached is a new patch that refactors things a bit to pass the
ParseState into functions such as PrepareQuery() and ExecuteQuery()
in
Peter Eisentraut writes:
> On 2019-11-08 09:03, Pavel Stehule wrote:
>> Minimally on SQL level is not possible do prepare on execute. So execute
>> should be evaluate as one step.
> Well, that's kind of the question that is being discussed in this thread.
Yeah. Having now taken a quick look at
pá 8. 11. 2019 v 13:34 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 2019-11-08 09:03, Pavel Stehule wrote:
> > Parse analysis of EXECUTE does not access any tables, so if I
> > understood
> > this correctly, this concern doesn't apply here.
> >
> >
> > i
On 2019-11-08 09:03, Pavel Stehule wrote:
Parse analysis of EXECUTE does not access any tables, so if I
understood
this correctly, this concern doesn't apply here.
it should not be true - the subquery can be a expression.
Arguments of EXECUTE cannot be subqueries.
Minimally on SQ
pá 8. 11. 2019 v 8:54 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 2019-11-08 08:13, Pavel Stehule wrote:
> > I dug into repository and found that transformExecuteStmt existed at
> > the time of implementing PREPARE-EXECUTE statements(28e82066a1) and
> >
On 2019-11-08 08:13, Pavel Stehule wrote:
I dug into repository and found that transformExecuteStmt existed at
the time of implementing PREPARE-EXECUTE statements(28e82066a1) and
removed by the commit b9527e9840 which is related to
plan-invalidation.
git show -s --format=%B b
po 4. 11. 2019 v 8:53 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 2019-11-02 16:00, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> This patch moves the parse analysis component of ExecuteQuery() and
> >> EvaluateParams() into a new transformExecuteStmt() that i
út 5. 11. 2019 v 11:28 odesílatel Kyotaro Horiguchi
napsal:
> Hello.
>
> At Mon, 4 Nov 2019 08:53:18 +0100, Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote in
> > On 2019-11-02 16:00, Tom Lane wrote:
> > > Peter Eisentraut writes:
> > >> This patch moves the parse analysis component
Hello.
At Mon, 4 Nov 2019 08:53:18 +0100, Peter Eisentraut
wrote in
> On 2019-11-02 16:00, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> This patch moves the parse analysis component of ExecuteQuery() and
> >> EvaluateParams() into a new transformExecuteStmt() that is called from
> >> tran
Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 7c5bc30a02ec34646c8e49af1499fe4113bc9e5e Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Thu, 31 Oct 2019 09:54:07 +0100
Subject: [PATCH] Refactor parse analysis of EXE
Peter Eisentraut writes:
> This patch moves the parse analysis component of ExecuteQuery() and
> EvaluateParams() into a new transformExecuteStmt() that is called from
> transformStmt().
Uhmm ... no actual patch attached?
regards, tom lane
This patch moves the parse analysis component of ExecuteQuery() and
EvaluateParams() into a new transformExecuteStmt() that is called from
transformStmt(). This makes EXECUTE behave more like other utility
commands.
Effects are that error messages can have position information (see
regression t
14 matches
Mail list logo
