On 15/08/10 10:31, Boxuan Zhai wrote:
On Sun, Aug 15, 2010 at 4:05 AM, Heikki Linnakangas<
heikki.linnakan...@enterprisedb.com> wrote:
Thanks. I went through this, fixing all the spurious end-of-line whitespace
first with "git apply --whitespace=fix", and then manually fixing comment
and whites
On Sun, Aug 15, 2010 at 4:05 AM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> On 11/08/10 11:11, Boxuan Zhai wrote:
>
>> The new patch is done. I named it as merge_v102. (1 means it is the
>> non-inheritance merge command, 02 means this is the second time of fixing
>> reporte
Excerpts from Peter Eisentraut's message of mié ago 11 11:23:19 -0400 2010:
> On fre, 2010-08-06 at 08:12 +0100, Simon Riggs wrote:
> > Given that Peter is now attending SQL Standards meetings, I would
> > suggest we leave out my suggestion above, for now. We have time to
> > raise this at standard
On fre, 2010-08-06 at 08:12 +0100, Simon Riggs wrote:
> Given that Peter is now attending SQL Standards meetings, I would
> suggest we leave out my suggestion above, for now. We have time to
> raise this at standards meetings and influence the outcome and then
> follow later.
I'm not actually atte
On fre, 2010-08-06 at 10:28 +0300, Heikki Linnakangas wrote:
> IMO the UPDATE/DELETE/INSERT actions should fire the respective
> statement level triggers, but the MERGE itself should not.
Yes, SQL defines the triggering of triggers as part of the modification
of rows, not as part of any particula
On Wed, Aug 11, 2010 at 12:18 PM, Boxuan Zhai wrote:
>
>
> On Wed, Aug 11, 2010 at 12:14 PM, Greg Smith wrote:
>
>> Boxuan Zhai wrote:
>>
>>> I just found that no Assert() works in my codes. I think it is because
>>> the assertion is no enabled. How to enable assertion. To define
>>> USE_ASSERT_
On Wed, Aug 11, 2010 at 12:14 PM, Greg Smith wrote:
> Boxuan Zhai wrote:
>
>> I just found that no Assert() works in my codes. I think it is because the
>> assertion is no enabled. How to enable assertion. To define
>> USE_ASSERT_CHECKING somewhere?
>>
>
> When you run "configure" before "make",
Boxuan Zhai wrote:
I just found that no Assert() works in my codes. I think it is because
the assertion is no enabled. How to enable assertion. To define
USE_ASSERT_CHECKING somewhere?
When you run "configure" before "make", use "--enable-cassert". The
normal trio for working on the PostgreS
On Tue, Aug 10, 2010 at 10:29 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> On 10/08/10 12:08, Boxuan Zhai wrote:
>
>> Thanks for your feedback. I fixed all the above waring bugs. Find the new
>> patch in attachement.
>>
>
> Thanks.
>
> I'm getting an assertion failure wit
On 10/08/10 12:08, Boxuan Zhai wrote:
Thanks for your feedback. I fixed all the above waring bugs. Find the new
patch in attachement.
Thanks.
I'm getting an assertion failure with this statement:
CREATE TABLE foo (id int4);
MERGE into foo t
USING (select id FROM generate_series(1,5) id) AS s
On 10/08/10 06:03, Boxuan Zhai wrote:
I have put everything in one patch, against the latest git repository. The
program is tested on my machine.
Thanks! I get a few compiler warnings:
analyze.c: In function ‘transformMergeStmt’:
analyze.c:2476: warning: unused variable ‘lastaction’
gram.y: In
On 09/08/10 14:47, Heikki Linnakangas wrote:
On 07/08/10 10:58, Boxuan Zhai wrote:
I have just finished a new patch, with the following feature:
Please include the regression tests in the patch too
And the docs changes too.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprised
On 07/08/10 10:58, Boxuan Zhai wrote:
I have just finished a new patch, with the following feature:
Please include the regression tests in the patch too. Also, I note that
there's a few merge conflicts when applied over CVS HEAD from today, can
you please fix the bitrot?
--
Heikki Linnaka
On tor, 2010-08-05 at 16:35 +0100, Simon Riggs wrote:
> * DELETE is an extension to the standard, though supported by Oracle,
> DB2 and SQLServer and damn useful
-> SQL:2011
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.po
On Fri, 2010-08-06 at 16:26 +0800, Boxuan Zhai wrote:
> So, we need to add both DO NOTHING and RAISE ERROR actions in the
> MERGE command now !? What will RAISE ERROR do?
Let's get the rest of it working first. This would be a later extension,
though I think an important one for our developers.
On Fri, Aug 6, 2010 at 3:53 PM, Simon Riggs wrote:
> On Fri, 2010-08-06 at 10:28 +0300, Heikki Linnakangas wrote:
> > On 06/08/10 10:12, Simon Riggs wrote:
> > > So DO NOTHING is the default and implies silently ignoring rows. RAISE
> > > ERROR is the opposite.
> > >
> > > Coding for those seems
On Fri, Aug 6, 2010 at 3:41 PM, Simon Riggs wrote:
> On Fri, 2010-08-06 at 10:28 +0300, Heikki Linnakangas wrote:
>
> > > SQL:2011 makes no mention of how MERGE should react to statement level
> > > triggers. MERGE is not a trigger action even. Given considerable
> > > confusion in this area, IMH
On Fri, 2010-08-06 at 10:28 +0300, Heikki Linnakangas wrote:
> On 06/08/10 10:12, Simon Riggs wrote:
> > So DO NOTHING is the default and implies silently ignoring rows. RAISE
> > ERROR is the opposite.
> >
> > Coding for those seems very easy, its just a question of "should we do
> > it?". DB2 has
On Fri, 2010-08-06 at 10:28 +0300, Heikki Linnakangas wrote:
> > SQL:2011 makes no mention of how MERGE should react to statement level
> > triggers. MERGE is not a trigger action even. Given considerable
> > confusion in this area, IMHO we should just say the MERGE does not call
> > statement tri
On 06/08/10 10:12, Simon Riggs wrote:
So DO NOTHING is the default and implies silently ignoring rows. RAISE
ERROR is the opposite.
Coding for those seems very easy, its just a question of "should we do
it?". DB2 has it; SQL:2008 does not. But then SQL:2008 followed the DB2
introduction of AND c
On Fri, 2010-08-06 at 09:39 +0800, Boxuan Zhai wrote:
> Besides, (I mean no offense, but) can this method really avoid losing
> row?
Not as you just specified, no.
You need *both* actions of RAISE ERROR and DO NOTHING, or you may as
well have neither.
(1) Natural style allows missing rows if
On 06/08/10 04:39, Boxuan Zhai wrote:
I have seen a lively discussion about the DO NOTING action in MERGE command.
And, I think most people want it. So it will be added to my next patch.
Before the implementation, I still have some questions to confirm:
1. If we have a DO NOTHING action specifi
Dear All,
I have seen a lively discussion about the DO NOTING action in MERGE command.
And, I think most people want it. So it will be added to my next patch.
Before the implementation, I still have some questions to confirm:
1. If we have a DO NOTHING action specified, it should be the last WHE
On Thu, Aug 5, 2010 at 7:25 AM, Simon Riggs wrote:
> Also had these fragments as well, if they're still useful. Probably just
> useful as pointers as to what else to change to include the docs.
>
>
> The tests and docs were written from SQL standard, so any deviations
> would need to be flagged. T
On Thu, Aug 5, 2010 at 11:35 AM, Simon Riggs wrote:
> * It appears we would be in violation of the standard on
> 14.12 General Rule 6 a) i) 2) B), p.890
> (Oh, I wish I was joking, there really is such a paragraph number)
Just shoot me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
T
On Thu, 2010-08-05 at 18:17 +0300, Heikki Linnakangas wrote:
> On 05/08/10 17:22, Simon Riggs wrote:
> > On Thu, 2010-08-05 at 21:55 +0800, Boxuan Zhai wrote:
> >
> >> In the contrary, Simon's instruction says that the DEFAULT action for
> >> the tuple caught by no actions is
> >> WHEN NOT MATCHED
On 05/08/10 17:22, Simon Riggs wrote:
On Thu, 2010-08-05 at 21:55 +0800, Boxuan Zhai wrote:
In the contrary, Simon's instruction says that the DEFAULT action for
the tuple caught by no actions is
WHEN NOT MATCHED THEN INSERT DEFAULT VALUES
From the user's point of view, these two kinds of MER
On Thu, 2010-08-05 at 21:55 +0800, Boxuan Zhai wrote:
> In the contrary, Simon's instruction says that the DEFAULT action for
> the tuple caught by no actions is
> WHEN NOT MATCHED THEN INSERT DEFAULT VALUES
>
> From the user's point of view, these two kinds of MERGE command may
> have not much
On Thu, Aug 05, 2010 at 09:55:29PM +0800, Boxuan Zhai wrote:
> On Thu, Aug 5, 2010 at 7:25 PM, Simon Riggs wrote:
>
> > On Thu, 2010-08-05 at 12:29 +0300, Heikki Linnakangas wrote:
> > > On 05/08/10 10:46, Simon Riggs wrote:
> > > > On Mon, 2008-04-21 at 21:08 +0100, Simon Riggs wrote:
> > > >> T
On Thu, Aug 5, 2010 at 7:25 PM, Simon Riggs wrote:
> On Thu, 2010-08-05 at 12:29 +0300, Heikki Linnakangas wrote:
> > On 05/08/10 10:46, Simon Riggs wrote:
> > > On Mon, 2008-04-21 at 21:08 +0100, Simon Riggs wrote:
> > >> The following two files specify the behaviour of the MERGE statement
> and
On Thu, 2010-08-05 at 12:29 +0300, Heikki Linnakangas wrote:
> On 05/08/10 10:46, Simon Riggs wrote:
> > On Mon, 2008-04-21 at 21:08 +0100, Simon Riggs wrote:
> >> The following two files specify the behaviour of the MERGE statement and
> >> how it will work in the world of PostgreSQL.
> >
> >> The
On 05/08/10 10:46, Simon Riggs wrote:
On Mon, 2008-04-21 at 21:08 +0100, Simon Riggs wrote:
The following two files specify the behaviour of the MERGE statement and
how it will work in the world of PostgreSQL.
The HTML file was generated from SGML source, though the latter is not
included her
On Mon, 2008-04-21 at 21:08 +0100, Simon Riggs wrote:
> The following two files specify the behaviour of the MERGE statement and
> how it will work in the world of PostgreSQL.
> The HTML file was generated from SGML source, though the latter is not
> included here for clarity.
Enclose merge.sgml
On Mon, 2008-04-28 at 11:57 +0300, Marko Kreen wrote:
> On 4/25/08, Robert Treat <[EMAIL PROTECTED]> wrote:
> > On Thursday 24 April 2008 23:40, Tom Lane wrote:
> > > Robert Treat <[EMAIL PROTECTED]> writes:
> > > > Perhaps a better option would be to implement Merge per spec, and then
> > > > i
On 4/25/08, Robert Treat <[EMAIL PROTECTED]> wrote:
> On Thursday 24 April 2008 23:40, Tom Lane wrote:
> > Robert Treat <[EMAIL PROTECTED]> writes:
> > > Perhaps a better option would be to implement Merge per spec, and then
> > > implement a "replace into" command for the oltp scenario. This w
On Fri, 2008-04-25 at 09:10 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
> > I'm now happy that we can get a spec-compliant end result by always
> > forcing NOT MATCHED rules to occur before MATCHED rules, when we have at
> > least one unique index.
>
> ... and raise an ERROR when there is
Simon Riggs wrote:
On Fri, 2008-04-25 at 10:03 +0300, Hannu Krosing wrote:
On Tue, 2008-04-22 at 00:24 +0100, Simon Riggs wrote:
On Mon, 2008-04-21 at 16:38 -0400, A.M. wrote:
"MERGE will not invoke Rules." Does this imply that MERGE cannot be
used on views or that the resulting INSERTs or U
On Thursday 24 April 2008 23:40, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Perhaps a better option would be to implement Merge per spec, and then
> > implement a "replace into" command for the oltp scenario. This way you
> > keep the spec behavior for the spec syntax, and have
Simon Riggs wrote:
> I'm now happy that we can get a spec-compliant end result by always
> forcing NOT MATCHED rules to occur before MATCHED rules, when we have at
> least one unique index.
... and raise an ERROR when there is no unique index?
--
Alvaro Herreraht
Robert Treat wrote:
Perhaps a better option would be to implement Merge per spec, and then
implement a "replace into" command for the oltp scenario. This way you keep
the spec behavior for the spec syntax, and have a clearly non-spec command
for non-spec behavior.
MySQL's "REPLACE IN
On Fri, 2008-04-25 at 10:03 +0300, Hannu Krosing wrote:
> On Tue, 2008-04-22 at 00:24 +0100, Simon Riggs wrote:
> > On Mon, 2008-04-21 at 16:38 -0400, A.M. wrote:
> >
> > > "MERGE will not invoke Rules." Does this imply that MERGE cannot be
> > > used on views or that the resulting INSERTs or UP
On Apr 25, 2008, at 3:28 AM, Simon Riggs wrote:
I recently came across the expression "YAGNI", and think it's
probably
pretty relevant to this discussion:
http://en.wikipedia.org/wiki/You_Ain't_Gonna_Need_It
In matters of technical implementation, I follow you almost without
question, and ver
On Thu, 2008-04-24 at 20:28 +0100, Simon Riggs wrote:
> With MERGE, we would need to do it like this:
>
> 1. If there are any WHEN NOT MATCHED clauses that trigger INSERTs, then
> attempt to apply them first, no matter what order they were in with
> respect to the WHEN MATCHED clauses. Start loop
On Fri, 2008-04-25 at 11:07 +0200, Petr Jelinek wrote:
> Another thing is, the table on which we do SELECT (the one in USING) can
> be different from target table and we can use columns from that table in
> INSERT/UPDATE statement (probably one the reasons why spec says the
> "SELECT" query has
Tom Lane wrote:
Robert Treat <[EMAIL PROTECTED]> writes:
Perhaps a better option would be to implement Merge per spec, and then
implement a "replace into" command for the oltp scenario. This way you keep
the spec behavior for the spec syntax, and have a clearly non-spec command
for non-spec b
On Thu, Apr 24, 2008 at 11:40:22PM -0400, Tom Lane wrote:
> In that case, it's a fair question to ask just who will use the "spec"
> syntax. As far as I can tell from years of watching the mailing lists,
> there is plenty of demand for a concurrent-safe insert-or-update
> behavior, and *exactly ze
On Thu, 2008-04-24 at 23:40 -0400, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > Perhaps a better option would be to implement Merge per spec, and then
> > implement a "replace into" command for the oltp scenario. This way you
> > keep
> > the spec behavior for the spec syntax,
On Tue, 2008-04-22 at 00:24 +0100, Simon Riggs wrote:
> On Mon, 2008-04-21 at 16:38 -0400, A.M. wrote:
>
> > "MERGE will not invoke Rules." Does this imply that MERGE cannot be
> > used on views or that the resulting INSERTs or UPDATEs do not work on
> > views?
>
> Yes, that's right. Just li
Robert Treat <[EMAIL PROTECTED]> writes:
> Perhaps a better option would be to implement Merge per spec, and then
> implement a "replace into" command for the oltp scenario. This way you keep
> the spec behavior for the spec syntax, and have a clearly non-spec command
> for non-spec behavior.
On Thursday 24 April 2008 12:19, Tom Lane wrote:
> Decibel! <[EMAIL PROTECTED]> writes:
> > That really strikes me as taking the "MySQL route". If push comes to
> > shove, I'll take a MERGE with race conditions over no merge at all,
> > but I think it's very important that it does the right thing.
[EMAIL PROTECTED] (Decibel!) writes:
> On Apr 22, 2008, at 1:17 PM, Gregory Stark wrote:
>> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>>
>>> As I've said elsewhere, we could have it lock each row, its just more
>>> overhead if we do and not necessary at all for bulk data merging.
>>>
>>> I'll pres
On Thu, 2008-04-24 at 12:19 -0400, Tom Lane wrote:
> Decibel! <[EMAIL PROTECTED]> writes:
> > That really strikes me as taking the "MySQL route". If push comes to
> > shove, I'll take a MERGE with race conditions over no merge at all,
> > but I think it's very important that it does the right t
Decibel! <[EMAIL PROTECTED]> writes:
> That really strikes me as taking the "MySQL route". If push comes to
> shove, I'll take a MERGE with race conditions over no merge at all,
> but I think it's very important that it does the right thing. Just
> because the spec doesn't say anything about
On Apr 22, 2008, at 3:20 PM, Martijn van Oosterhout wrote:
On Tue, Apr 22, 2008 at 02:19:24PM -0500, Decibel! wrote:
But no matter how this is done, I think we need to handle the race
conditions, and handle them by default. If people *really* know what
they're doing, they can disable the row lo
On Tue, Apr 22, 2008 at 02:19:24PM -0500, Decibel! wrote:
> But no matter how this is done, I think we need to handle the race
> conditions, and handle them by default. If people *really* know what
> they're doing, they can disable the row locking (perhaps one way to
> do this would be to gra
On Apr 22, 2008, at 1:17 PM, Gregory Stark wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
As I've said elsewhere, we could have it lock each row, its just more
overhead if we do and not necessary at all for bulk data merging.
I'll presume we want locking as an option, unless people say
oth
On Apr 22, 2008, at 1:47 PM, Simon Riggs wrote:
On Mon, 2008-04-21 at 22:27 -0400, Gregory Stark wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
Unrelated to rule processing, you did read the bit about MERGE and
race
conditions? ISTM that MERGE as it stands isn't very useful for
anything
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> As I've said elsewhere, we could have it lock each row, its just more
> overhead if we do and not necessary at all for bulk data merging.
>
> I'll presume we want locking as an option, unless people say otherwise.
It's not so simple. If you look for a r
On Mon, 2008-04-21 at 22:27 -0400, Gregory Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > Unrelated to rule processing, you did read the bit about MERGE and race
> > conditions? ISTM that MERGE as it stands isn't very useful for anything
> > other than large data loads since its go
On Tue, 2008-04-22 at 10:02 +0200, Martijn van Oosterhout wrote:
> On Tue, Apr 22, 2008 at 08:24:58AM +0100, Simon Riggs wrote:
> > The way MERGE works we first test to see if it matches or not, then if
> > not matched we would activate the NOT MATCHED action, which standard
> > says must be an ins
On Tue, Apr 22, 2008 at 08:24:58AM +0100, Simon Riggs wrote:
> The way MERGE works we first test to see if it matches or not, then if
> not matched we would activate the NOT MATCHED action, which standard
> says must be an insert. The gap between the two actions allows a race
> condition to exist.
On Mon, 2008-04-21 at 21:57 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
> > Unrelated to rule processing, you did read the bit about MERGE and race
> > conditions? ISTM that MERGE as it stands isn't very useful for anything
> > other than large data loads since its going to cause problems
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Unrelated to rule processing, you did read the bit about MERGE and race
> conditions? ISTM that MERGE as it stands isn't very useful for anything
> other than large data loads since its going to cause problems if used
> concurrently.
If there are race c
Simon Riggs wrote:
> Unrelated to rule processing, you did read the bit about MERGE and race
> conditions? ISTM that MERGE as it stands isn't very useful for anything
> other than large data loads since its going to cause problems if used
> concurrently.
But that's how the committee designed it,
On Mon, 2008-04-21 at 20:28 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Mon, 2008-04-21 at 16:38 -0400, A.M. wrote:
> >> "MERGE will not invoke Rules." Does this imply that MERGE cannot be
> >> used on views or that the resulting INSERTs or UPDATEs do not work on
> >
On Mon, 2008-04-21 at 20:28 -0400, Tom Lane wrote:
> In fact, I don't even want to think
> about what kind of crock you're going to need in order to get it through
> the planner without also going through the rewriter.
Hmmm, I hadn't thought I might be adding work rather than avoiding it.
I'll g
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2008-04-21 at 16:38 -0400, A.M. wrote:
>> "MERGE will not invoke Rules." Does this imply that MERGE cannot be
>> used on views or that the resulting INSERTs or UPDATEs do not work on
>> views?
> Yes, that's right. Just like COPY.
I find this t
On Mon, 2008-04-21 at 16:38 -0400, A.M. wrote:
> "MERGE will not invoke Rules." Does this imply that MERGE cannot be
> used on views or that the resulting INSERTs or UPDATEs do not work on
> views?
Yes, that's right. Just like COPY. That seems fine to me because you're
likely to be doing a ME
On Apr 21, 2008, at 4:08 PM, Simon Riggs wrote:
The following two files specify the behaviour of the MERGE statement
and
how it will work in the world of PostgreSQL. In places, this
supercedes
my recent commentary on MERGE, particularly with regard to triggers.
Neither of these files is in
On Mon, 2008-04-21 at 22:18 +0200, Pavel Stehule wrote:
> would you support RETURNING clause?
I wouldn't rule it out completely, but not in the first implementation
because
- its more work
- its not in the SQL Standard
- neither Oracle nor DB2 support it either, so its only going to provide
incom
Hello Simon,
would you support RETURNING clause?
Regards
Pavel Stehule
On 21/04/2008, Simon Riggs <[EMAIL PROTECTED]> wrote:
> The following two files specify the behaviour of the MERGE statement and
> how it will work in the world of PostgreSQL. In places, this supercedes
> my recent commenta
The following two files specify the behaviour of the MERGE statement and
how it will work in the world of PostgreSQL. In places, this supercedes
my recent commentary on MERGE, particularly with regard to triggers.
Neither of these files is intended for CVS.
The HTML file was generated from SGML
72 matches
Mail list logo
