On 2015-05-19 22:50:54 -0700, Peter Geoghegan wrote:
> On Tue, May 19, 2015 at 2:23 PM, Andres Freund wrote:
> > Pushed.
>
> I eyeballed the commit, and realized that I made a trivial error. New
> patch attached fixing that.
>
> Sorry for not getting this fix completely right first time around.
On Tue, May 19, 2015 at 2:23 PM, Andres Freund wrote:
> Pushed.
I eyeballed the commit, and realized that I made a trivial error. New
patch attached fixing that.
Sorry for not getting this fix completely right first time around.
Don't know how I missed it.
--
Peter Geoghegan
diff --git a/src/ba
On 2015-05-18 19:09:27 -0700, Peter Geoghegan wrote:
> On Mon, May 18, 2015 at 2:09 PM, Peter Geoghegan wrote:
> > You pointed out that the reason for this trivial bug on Jabber, but
> > here's the obvious fix, including an EXPLAIN regression test.
>
> Also, I attach a patch adding ruleutils.c de
On Mon, May 18, 2015 at 2:09 PM, Peter Geoghegan wrote:
> You pointed out that the reason for this trivial bug on Jabber, but
> here's the obvious fix, including an EXPLAIN regression test.
Also, I attach a patch adding ruleutils.c deparsing support for INSERT
statement target aliases. This was p
On Sat, May 16, 2015 at 11:48 PM, Peter Geoghegan wrote:
> FYI, I found an unrelated bug within ruleutils.c (looks like the
> targetlist kludge in set_deparse_planstate() isn't sufficiently
> general):
>
> postgres=# explain insert into upsert as u values('Bat', 'Bar') on
> conflict (key) do updat
On Mon, May 18, 2015 at 1:49 PM, Peter Geoghegan wrote:
> Here is a cumulative version of what was previously posted.
BTW, this could result in more calls to get_opclass_family() and
get_opclass_input_type() than before. However, because we'll have
eliminated so many candidates (e.g. by seeing th
On Tue, May 12, 2015 at 3:16 PM, Andres Freund wrote:
> Could you rebase and adjust your patch? I'd rather have the inference
> structure refactoring separate.
I realized that I didn't split out the patch as requested.
Here is a cumulative version of what was previously posted.
Thanks
--
Peter
On Tue, May 12, 2015 at 4:23 PM, Peter Geoghegan wrote:
> Rebased version of patch is attached.
FYI, I found an unrelated bug within ruleutils.c (looks like the
targetlist kludge in set_deparse_planstate() isn't sufficiently
general):
postgres=# explain insert into upsert as u values('Bat', 'Bar
On Tue, May 12, 2015 at 3:18 PM, Peter Geoghegan wrote:
> On Tue, May 12, 2015 at 3:16 PM, Andres Freund wrote:
>> Could you rebase and adjust your patch? I'd rather have the inference
>> structure refactoring separate.
>
> Sure.
Rebased version of patch is attached.
--
Peter Geoghegan
From cc
On Tue, May 12, 2015 at 3:16 PM, Andres Freund wrote:
> Could you rebase and adjust your patch? I'd rather have the inference
> structure refactoring separate.
Sure.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On 2015-05-12 23:40:47 +0200, Andres Freund wrote:
> That's just a straight up bug. expression_tree_walker (called via
> ChangeVarNodes) did not know about exclRelTlist, leading to
> fix_join_expr() not matching the excluded vars to the excluded
> relation/tlist.
I've fixed these, and added a mini
On Tue, May 12, 2015 at 2:40 PM, Andres Freund wrote:
>> It's not as if I have no idea. ReplaceVarsFromTargetList() is probably
>> quite confused by all this, because the passed nomatch_varno argument
>> is often rt_index -- but what about EXCLUDED.*? adjustJoinTreeList()
>> does not know anything
On 2015-05-11 20:16:00 -0700, Peter Geoghegan wrote:
> On Mon, May 11, 2015 at 7:34 PM, Andres Freund wrote:
> > You should try to understand why it's failing. Just prohibiting the
> > rules, without understanding what's actually going on, could very well
> > hide a real bug.
>
> It's not as if I
On Mon, May 11, 2015 at 7:34 PM, Andres Freund wrote:
> You should try to understand why it's failing. Just prohibiting the
> rules, without understanding what's actually going on, could very well
> hide a real bug.
It's not as if I have no idea. ReplaceVarsFromTargetList() is probably
quite conf
On 2015-05-11 19:33:02 -0700, Peter Geoghegan wrote:
> On Mon, May 11, 2015 at 7:22 PM, Peter Geoghegan wrote:
> > You just get an error within the
> > optimizer following rewriting of a query involving the application of
> > a rule that specifies an ON CONFLICT DO UPDATE alternative/DO INSTEAD
>
On Mon, May 11, 2015 at 7:22 PM, Peter Geoghegan wrote:
> You just get an error within the
> optimizer following rewriting of a query involving the application of
> a rule that specifies an ON CONFLICT DO UPDATE alternative/DO INSTEAD
> action. I found it would say: "variable not found in subplan
On Mon, May 11, 2015 at 7:11 PM, Andres Freund wrote:
> Do I understand correctly that you cut this out because there
> essentially was a ruleutils bug with with EXCLUDED? If so, I don't find
> that acceptable. I'm pretty strictly convincded that independent of rule
> support, we shouldn't add thi
HI,
Don't have time to go through this in depth.
On 2015-05-11 18:53:22 -0700, Peter Geoghegan wrote:
> Note that the patch proposes to de-support CREATE RULE with an
> alternative action involving ON CONFLICT DO UPDATE. Such a rule seems
> particularly questionable to me, and I'm pretty sure it
On Mon, May 11, 2015 at 6:53 PM, Peter Geoghegan wrote:
> Attached patch fixes some issues with ON CONFLICT DO UPDATE/DO
> NOTHING. There is a commit message which explains the changes at a
> high level.
I just realized that there is a silly bug here. Attached is a fix that
applies on top of the
Attached patch fixes some issues with ON CONFLICT DO UPDATE/DO
NOTHING. There is a commit message which explains the changes at a
high level. The only real bug fix is around deparsing by ruleutils.c.
Note that the patch proposes to de-support CREATE RULE with an
alternative action involving ON CON
20 matches
Mail list logo
