Prev: Need a Promotion for a good life. alamode adenia absonant
Next: [HACKERS] PostGIS vs. PGXS in 9.0beta3
From: David Fetter on 3 Aug 2010 18:45
On Tue, Aug 03, 2010 at 03:14:02PM -0700, Josh Berkus wrote:
>
> > And, I have tested the running of MERGE command with different
> > situations. I am sorry that I didn't create regression test files,
> > because I am not sure how to add new files in the git package.
> > But, I have written web pages in Postgres Wiki. I explain the
> > details of my implementation and a set of testing examples.
>
> Can someone help Boxuan with how to write regression tests?

Happy to. I'll start this evening PDT or tomorrow :)

Cheers,
David.
--
David Fetter <david(a)fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter(a)gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Greg Smith on 3 Aug 2010 19:19
Boxuan Zhai wrote:
> I think there are no redundant lines in this time's patch file.

It is much better. There are still more blank likes around the new code
you've added than are needed in many places, but that doesn't interfere
with reading the patch.

The main code formatting issue left you'll need to address eventually
are all the really long comments in there.


> And, I have tested the running of MERGE command with different
> situations. I am sorry that I didn't create regression test files,
> because I am not sure how to add new files in the git package.

git add <filename> ?

The tests you've put in there are the right general sort of things to
try out. The one example you gave does show an UPSERT being emulated by
MERGE, which is the #1 thing people are looking for initially.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(a)2ndQuadrant.com www.2ndQuadrant.us


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Boxuan Zhai on 4 Aug 2010 00:55
2010/8/4 Greg Smith <greg(a)2ndquadrant.com>

> Boxuan Zhai wrote:
>
>> I think there are no redundant lines in this time's patch file.
>>
>
> It is much better. There are still more blank likes around the new code
> you've added than are needed in many places, but that doesn't interfere with
> reading the patch.
>
> Sorry, it is my personal habit of leaving blanks around codes. I will chage
this if it doesn't follow the pgsql coding style.


> The main code formatting issue left you'll need to address eventually are
> all the really long comments in there.
>
> I will correct the long comments in the next patch.

>
>
> And, I have tested the running of MERGE command with different situations.
>> I am sorry that I didn't create regression test files, because I am not sure
>> how to add new files in the git package.
>>
>
> git add <filename> ?
>
> The tests you've put in there are the right general sort of things to try
> out. The one example you gave does show an UPSERT being emulated by MERGE,
> which is the #1 thing people are looking for initially.
>
> In fact, I have created a merge.sql with simple merge example. I put it in
the folder of /src/test/regress/sql/ and modified the serial_schedule file
to add a line of : test: merge
Is this correct?

But, I don't know how to run regress to test this sql file. My "make check"
fails when install the db. I think this is because I do it under a MinGW
environment and some parameters are not matched with the default setting of
postgres.
I can configure, make install , initdb and do sql query in psql successfully
in my machine. So the source code itself should be correct.

I put my merge.sql in attachment, in case anyone want to have a look.




>
> --
> Greg Smith 2ndQuadrant US Baltimore, MD
> PostgreSQL Training, Services and Support
> greg(a)2ndQuadrant.com www.2ndQuadrant.us <http://www.2ndquadrant.us/>
>
>
From: Boxuan Zhai on 4 Aug 2010 05:23
Dear Robert,

I am just considering that there may be some logical mistakes for my rule
rewriting strategy of MERGE actions.

In my current design, if we find that an action type, say UPDATE, is
replaced by INSTEAD rules, we will remove all the actions of this type from
the MERGE command, as if they are not be specified by user from the
beginning. See the test example in my pages for this situation.
https://wiki.postgresql.org/wiki/MergeTestExamples#With_INSTEAD_rules

Now,I am thinking that maybe we should keep the replaced actions in action
list, and just mark them to be "invalid". If one join tuple from the main
plan fits the condition of this action, we will do nothing on it.

This strategy is a little bit different with the current one. If we delete
an action, the tuples that meet it condition will be caught by other
actions. If we keep it, the tuples that match it will be skipped.

I think the new design is more logical, and I wonder your opinion on this
problem.

Yours Boxuan
From: Heikki Linnakangas on 4 Aug 2010 08:23
On 04/08/10 12:23, Boxuan Zhai wrote:
> I am just considering that there may be some logical mistakes for my rule
> rewriting strategy of MERGE actions.
>
> In my current design, if we find that an action type, say UPDATE, is
> replaced by INSTEAD rules, we will remove all the actions of this type from
> the MERGE command, as if they are not be specified by user from the
> beginning. See the test example in my pages for this situation.
> https://wiki.postgresql.org/wiki/MergeTestExamples#With_INSTEAD_rules
>
> Now,I am thinking that maybe we should keep the replaced actions in action
> list, and just mark them to be "invalid". If one join tuple from the main
> plan fits the condition of this action, we will do nothing on it.
>
> This strategy is a little bit different with the current one. If we delete
> an action, the tuples that meet it condition will be caught by other
> actions. If we keep it, the tuples that match it will be skipped.
>
> I think the new design is more logical, and I wonder your opinion on this
> problem.

So if I understood correctly, in the instead rule example you have at
the wiki page, the stock table should contain one row, with the same
balance it had before running the MERGE? Yeah, agreed, that's much more
logical.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Need a Promotion for a good life. alamode adenia absonant
Next: [HACKERS] PostGIS vs. PGXS in 9.0beta3