On Fri, Aug 13, 2010 at 2:33 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> On 13/08/10 09:27, Boxuan Zhai wrote:
>
>> I have renewed the merge.sql and merge.out in regress. Please have a look.
>>
>
> Thanks.
>
> Did you change the way DO INSTEAD rules are handled already?
On 13/08/10 09:27, Boxuan Zhai wrote:
I have renewed the merge.sql and merge.out in regress. Please have a look.
Thanks.
Did you change the way DO INSTEAD rules are handled already?
http://archives.postgresql.org/pgsql-hackers/2010-08/msg00151.php
--
Heikki Linnakangas
EnterpriseDB ht
On Thu, Aug 12, 2010 at 2:24 AM, Boxuan Zhai wrote:
> Sorry for the mismatch problem of regress. In fact, I am still unable to
> make the regression test run on my machine. When I try the command
> pg_regreess in /src/test/regress/, it always gives a FATAL error:
The intention is that you should
On Thu, Aug 12, 2010 at 12:49 AM, Greg Smith wrote:
> Tom Lane wrote:
>
>> Do we really think this is anywhere near committable now?
>>
>>
>
> There's a relatively objective standard for the first thing needed for
> commit--does it work?--in the form of the regression tests Simon put
> together b
Excerpts from Heikki Linnakangas's message of mié ago 11 10:52:24 -0400 2010:
> On 11/08/10 17:45, Simon Riggs wrote:
> > We've seen it time and time again
> > that big projects that aim to deliver towards end of a release cycle
> > interfere with dev of other projects and leave loose ends from
>
Tom Lane wrote:
Do we really think this is anywhere near committable now?
There's a relatively objective standard for the first thing needed for
commit--does it work?--in the form of the regression tests Simon put
together before development. I just tried the latest merge_v102.patch
(reg
Robert Haas writes:
> On Wed, Aug 11, 2010 at 11:23 AM, Simon Riggs wrote:
>> Well, if we go off chasing this particular goose then we will set
>> ourselves back at least one commitfest. I'd rather work towards having a
>> fully committable patch without inheritance sooner than an even bigger
>>
On Wed, Aug 11, 2010 at 11:23 AM, Simon Riggs wrote:
> Well, if we go off chasing this particular goose then we will set
> ourselves back at least one commitfest. I'd rather work towards having a
> fully committable patch without inheritance sooner than an even bigger
> patch arriving later in the
On Wed, 2010-08-11 at 11:03 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Wed, 2010-08-11 at 13:25 +0300, Heikki Linnakangas wrote:
> >> I concur that Boxuan's suggested "difficult" approach seems like the
> >> right one.
>
> > Right, but you've completely ignored my proposal: lets do thi
Simon Riggs writes:
> On Wed, 2010-08-11 at 13:25 +0300, Heikki Linnakangas wrote:
>> I concur that Boxuan's suggested "difficult" approach seems like the
>> right one.
> Right, but you've completely ignored my proposal: lets do this in two
> pieces. Get what we have now ready to commit, then a
On 11/08/10 17:45, Simon Riggs wrote:
It seems clear that your work in this area will interfere with the work
on partitioning and insert routing.
Nothing concrete has come out of that work yet. And we should have MERGE
work with inherited tables, regardless of any future work that may
happen
On Wed, 2010-08-11 at 22:09 +0800, Boxuan Zhai wrote:
> One more thing I want to point out is that, the INSERT is also an
> inheritable action in MERGE. For a plain INSERT command, all the
> inserted tuples are put in the target table ONLY. It is easy to
> understand. We don't want to duplicate a
On Wed, Aug 11, 2010 at 10:09 AM, Boxuan Zhai wrote:
> PS: Since I have taken this project, I will do my best to make it perfect.
> I will keep working on MERGE until it is really finished, even after the
> gSoC. (unless you guys has other plans).
That is great to hear!
FWIW, I agree with Heikki
On Wed, Aug 11, 2010 at 4:45 PM, Simon Riggs wrote:
> On Tue, 2010-08-10 at 17:15 +0300, Heikki Linnakangas wrote:
> > On 10/08/10 12:38, Boxuan Zhai wrote:
> > > The difficult way is to generate the plans for children table in
> planner, as
> > > the other commands like UPDATE and DELETE. Howev
On Wed, 2010-08-11 at 15:53 +0300, Heikki Linnakangas wrote:
> On 11/08/10 14:44, Simon Riggs wrote:
> > On Wed, 2010-08-11 at 13:25 +0300, Heikki Linnakangas wrote:
> >
> >> I concur that Boxuan's suggested "difficult" approach seems like the
> >> right one.
> >
> > Right, but you've completely ig
On 11/08/10 14:44, Simon Riggs wrote:
On Wed, 2010-08-11 at 13:25 +0300, Heikki Linnakangas wrote:
I concur that Boxuan's suggested "difficult" approach seems like the
right one.
Right, but you've completely ignored my proposal: lets do this in two
pieces. Get what we have now ready to commit
On Wed, Aug 11, 2010 at 4:27 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> On 10/08/10 12:38, Boxuan Zhai wrote:
>
>> These days I am considering what else can be done for MERGE, And, I
>> find inheritance tables in postgres is not supported by our MERGE command
>> yet.
>>
On Wed, 2010-08-11 at 13:25 +0300, Heikki Linnakangas wrote:
> I concur that Boxuan's suggested "difficult" approach seems like the
> right one.
Right, but you've completely ignored my proposal: lets do this in two
pieces. Get what we have now ready to commit, then add support for
partitioning
On 11/08/10 11:45, Simon Riggs wrote:
On Tue, 2010-08-10 at 17:15 +0300, Heikki Linnakangas wrote:
On 10/08/10 12:38, Boxuan Zhai wrote:
The difficult way is to generate the plans for children table in planner, as
the other commands like UPDATE and DELETE. However, because the structure of
MERG
On Tue, 2010-08-10 at 17:15 +0300, Heikki Linnakangas wrote:
> On 10/08/10 12:38, Boxuan Zhai wrote:
> > The difficult way is to generate the plans for children table in planner, as
> > the other commands like UPDATE and DELETE. However, because the structure of
> > MERGE plan is much more complex
On 10/08/10 12:38, Boxuan Zhai wrote:
These days I am considering what else can be done for MERGE, And, I
find inheritance tables in postgres is not supported by our MERGE command
yet.
I played with your latest patch version a bit, and actually, it seems to
me that inherited tables work just f
On 10/08/10 12:38, Boxuan Zhai wrote:
The difficult way is to generate the plans for children table in planner, as
the other commands like UPDATE and DELETE. However, because the structure of
MERGE plan is much more complex than the ordinary ModifyTable plans, this
job may not as simple as we exp
On tis, 2010-08-10 at 17:38 +0800, Boxuan Zhai wrote:
> I am not sure if inheritance of MERGE is needed by postgres.
Yes, it is.
> PS: for my investigation on the inheritance actions, I find that
> although the children tables are modified by the UPDATE or DELETE
> commands on their ancestor tabl
Hi,
These days I am considering what else can be done for MERGE, And, I
find inheritance tables in postgres is not supported by our MERGE command
yet.
Currently, MERGE command is only able to handle the target table itself, and
its children tables are not involved in the process.
I am not sure if
24 matches
Mail list logo
