n if you disagree with
> some aspects of the specification of MERGE, wouldn't it be valuable to
> implement it properly? Since I'm not the most knowledgeable person on this
> topic, where can I learn more about the reasons for this choice?"
A fair point.
--
Simon Riggs
ulary you're using isn't acceptable in this forum,
> 3) Personal attacks based on prejudice will not be tolerated.
Well, for 1) any comments are most welcome. I didn't see any evidence
of the other two.
All opinions welcome.
--
Simon Riggs http://www.2ndQuadrant.com
we would
like to solicit open feedback about how such a feature might look and
what aspects make it more/less likely to be adopted by Django.
Detailed feedback on ORM related issues is welcome.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Tra
gers fire
}
else
{
perform INSERT
AFTER INSERT triggers fire
}
INSTEAD OF triggers would fire on views only, so would be shown in the
above instead of the before triggers
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
which will defeat any attempt to
utilise an index to supply the ordering. i.e. it results in a
sequential scan and should be avoided.
I'd suggest an explicit option to change the ordering ASC | DESC,
which is matched by a SQL Standard feature.
--
Simon Riggs http://www.2ndQuad
Most likely, yes, so it looks like a bug fix now not an optimization.
> Also, multicolumn NOT IN lookups aren't
> supported on all databases (SQLite at least), so for that case NOT
> EXISTS semantics is going to happen anyways.
Yes, I think that's the clincher.
--
Simon Rig
hat weirdness that makes it hard to
optimize for, or at least, not-yet-optimized for in PostgreSQL.
In most cases it is the NOT EXISTS behaviour that people find natural
and normal anyway and that is the best mechanism to use.
> However, the query constuction to move the condition in
On Wed, Aug 10, 2011 at 3:08 PM, Anssi Kääriäinen
wrote:
> On 08/10/2011 03:18 PM, Simon Riggs wrote:
>
> That adds additional SELECT statements, which then extends a lock
> window between the check statement and the changes. It works, but in
> doing so it changes an optimis
ock check
failed and we can handle that. This keeps the locking optimistic and
doesn't add any additional SQL statements.
e.g.
UPDATE foo
SET col = newvalue, optimistic_lock_field = optimistic_lock_field + 1
WHERE pkcol = p_key
AND optimistic_lock_field = p_version
DELETE FROM foo
WHERE pk
gt; because constraint checks are *never* checked during testing. The small slew
> of bugs I found is a demonstration of that, to me.
No, sorry, nested transaction commands aren't supported.
> Anyhow, thank you once again Simon for shedding light on this for me.
No problem. Thank
On Sun, Jul 10, 2011 at 3:27 PM, Jim Dalton wrote:
> On Jul 10, 2011, at 3:13 AM, Simon Riggs wrote:
>
>> Maintaining the property of deferrable constraints seems important
>> here, so changing the deferrability of constraints, or overriding it
>> using the SET CONSTRAIN
e the ROLLBACK at *end* of
test. This will fire any outstanding checks. That way all constraint
checks will occur in the same place they would during a commit, yet we
can maintain the situation that the test ends with a rollback.
--
Simon Riggs http://www.2ndQuadrant.com/
Postgr
se statement directly? That way *any* legal
CASE statement can be used, without inventing new ORM syntax each
time.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
You received this message because you are subscribed to
ve is an
extension to the SQL standard.
SQL Standard formulation for this query syntax is new in SQL:2008 where
it is now called OFFSET ... FETCH ... To my knowledge only DB2 and
Postgres support the new standard syntax.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24
On Thu, 2010-07-08 at 15:58 -0500, Alex Gaynor wrote:
> On Thu, Jul 8, 2010 at 3:51 PM, Simon Riggs wrote:
> > On Mon, 2010-07-05 at 00:59 -0700, Simon Litchfield wrote:
> >> > If you can come up with answers to these points, I might get
> >> > interested. 1 and
can add LIMIT N onto
the bottom of every query by default, if a slice is not already defined.
That would work for all DBMS.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services
--
You received this message because you are subscribed to the Goo
sts.
I am just the messenger in this, carrying goodwill between projects.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services
--
You received this message because you are subscribed to the Google Groups
"Django developers"
d on Windows). So 8.2 is the minimum sensible version for
next release of Django, though 8.3 should be minimum recommended with
8.4 current stable release as dev target.
Happy to help with any issues arising from that move.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 2
18 matches
Mail list logo
