Tom Lane wrote:
>
> Sure, but what we were discussing was the "duplicate key" error issued
> by nbtinsert.c. AFAICS that depends on latest-commit status, not on
> snapshots. Perhaps that behavior is itself a bug? If so, how would
> you change it?
Addtional check seems to be needed in serializa
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> What I meant is e.g.
> update t set .. = .. where ...;
> PostgreSQL ignores the tuples which don't satisfy the
> where clause at the point when the query started(or
> when the transaction started in serializable mode)
> even though it happend to l
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Currently PostgreSQL ignores the update/deleted
> > tuples from the first which don't satisfy the
> > qualification at the point of snapshot.
>
> It does? It looks to me like we use SnapshotDirty time qual check
> and wait for any
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Currently PostgreSQL ignores the update/deleted
> tuples from the first which don't satisfy the
> qualification at the point of snapshot.
It does? It looks to me like we use SnapshotDirty time qual check
and wait for any uncommitted transaction. This
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > In Mikko's both examples, Transaction 1 has to see a tuple
> > which didn't exist at the beginning of the transaction
> > while checking duplicate error.
>
> I'm not sure about that. What if the "tuple that didn't exist" is
> an u
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> In Mikko's both examples, Transaction 1 has to see a tuple
> which didn't exist at the beginning of the transaction
> while checking duplicate error.
I'm not sure about that. What if the "tuple that didn't exist" is
an updated version of a row that did
Tom Lane wrote:
>
> Mikko Vierula <[EMAIL PROTECTED]> writes:
> > But all
> > those errors really are because of serialization problems. So shouldn't
> > I be receiving a error stating that?
>
> I disagree, because I don't think it's reasonable to expect the system
> to make that deduction. I pr
I've got some 'legacy' code that I'm dealing with - sometimes it will
receive query requests that are simply the union of two easier requests
it already knows the sql for.
These 'easier' queries have 'distincts' in them, and the code doesn't go
to the trouble of removing by hand when doing a un
Scott Royston <[EMAIL PROTECTED]> writes:
> I've seen a few postings in multiple newsgroups saying that in 7.1.x and
> up, literals in SQL statements are implicitly cast to strings.
That's an oversimplification: the implicit coercion of unknown literals
only happens when looking for an operator
> I've seen a few postings in multiple newsgroups saying that in 7.1.x and
> up, literals in SQL statements are implicitly cast to strings.
In some contexts, that statement is true, yes. The cases where this is
true is when the parser is trying to match literals with available
function calls. If
I've seen a few postings in multiple newsgroups saying that in 7.1.x and
up, literals in SQL statements are implicitly cast to strings.
For example in:
select distinct 'hello' from mytable;
the 'hello' is implicitly assumed to be 'hello'::text
However, in both 7.1.3, and a fresh build of 7.2b4
Mikko Vierula <[EMAIL PROTECTED]> writes:
> But all
> those errors really are because of serialization problems. So shouldn't
> I be receiving a error stating that?
I disagree, because I don't think it's reasonable to expect the system
to make that deduction. I prefer a specific error message te
12 matches
Mail list logo
