y with SQL standards. Even 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.
--
; 2) The disparaging vocabulary 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://w
reSQL community and 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 Dev
AFTER UPDATE triggers 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, T
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.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Servi
t; to choose those semantics.
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
ondition into the EXISTS
> subclause might be a bit more complex.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
You received this message because you are subscribed to the Google Groups
"Django deve
On Wed, Aug 10, 2011 at 3:08 PM, Anssi Kääriäinen
<anssi.kaariai...@thl.fi> 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
>
tion returns 0 rows then we know that the lock 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 optimisti
lem. Thanks to everybody working on Django.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this
On Sun, Jul 10, 2011 at 3:27 PM, Jim Dalton <jim.dal...@gmail.com> 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
>
ately before 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.
rough the case 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 ar
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, 24x7 Support, Training a
ttom 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 Google Groups
"Django devel
nger 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" group.
To post to th
s). 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, 24x7 Suppor
17 matches
Mail list logo
