On 2/8/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Just for the record, it's not the row constructor stuff that just got
> fixed, it's row-value comparison. We were able to construct rows
> correctly before, but we didn't compare them in the correct column-
> by-column fashion. Please call it by th
* Martijn van Oosterhout (kleptog@svana.org) wrote:
> On Wed, Feb 08, 2006 at 07:49:32AM -0500, Stephen Frost wrote:
> > Sounds like a bug, will it be in 8.1.3 or do we have to wait till 8.2
> > for it? Sounds very interesting indeed...
>
> Well, the bug is really that we accept the syntax but do
On Wed, Feb 08, 2006 at 07:49:32AM -0500, Stephen Frost wrote:
> * Martijn van Oosterhout (kleptog@svana.org) wrote:
> > It's in CVS HEAD, not 8.1
> >
> > > It seems to me that (x,y) > (a,b) means (x > a AND y > b) ... which is
> > > not exactly what you wanted... or I'm missing something ?
> >
>
* Martijn van Oosterhout (kleptog@svana.org) wrote:
> It's in CVS HEAD, not 8.1
>
> > It seems to me that (x,y) > (a,b) means (x > a AND y > b) ... which is
> > not exactly what you wanted... or I'm missing something ?
>
> Yes, it changed because someone pointed out that the behaviour in 8.1
> wa
On Wed, Feb 08, 2006 at 10:38:59AM +0100, Csaba Nagy wrote:
> Well, I've tested it a bit:
>
> db=# select version();
> version
>
> PostgreSQL 8.1.2 on i686-pc-lin
Well, I've tested it a bit:
db=# select version();
version
PostgreSQL 8.1.2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.3.5
(Debian 1:3.3.5-13)
(1 row)
db
Merlin Moncure <[EMAIL PROTECTED]> writes:
> IMO, the sql 92 row constructor was inserted for ISAM style key based
> table browsing without cursors...more or less a 'lost art' these days
> but still relevant. This is a key strategy in dealing with large
> tables. Blog entry is forthcoming :).
Ju
>> On Feb 8, 2006, at 11:17 , Merlin Moncure wrote:
>>
>> > The proper SQL construct without row constructor is:
>> >
>> > select * from t where
>> > a >= a1 and
>> > (a > a1 or b>= b1) and
>> > (a > a1 or b > b1 or c > c1)
>> > order by a,b,c limit 1^ no offset necessary
>> >
>> > confus
On Feb 8, 2006, at 11:35 , Merlin Moncure wrote:
On Feb 8, 2006, at 11:17 , Merlin Moncure wrote:
The proper SQL construct without row constructor is:
select * from t where
a >= a1 and
(a > a1 or b>= b1) and
(a > a1 or b > b1 or c > c1)
order by a,b,c limit 1^ no offset necessary
> On Feb 8, 2006, at 11:17 , Merlin Moncure wrote:
>
> > The proper SQL construct without row constructor is:
> >
> > select * from t where
> > a >= a1 and
> > (a > a1 or b>= b1) and
> > (a > a1 or b > b1 or c > c1)
> > order by a,b,c limit 1^ no offset necessary
> >
> > confused yet?
>
>
On Feb 8, 2006, at 11:17 , Merlin Moncure wrote:
The proper SQL construct without row constructor is:
select * from t where
a >= a1 and
(a > a1 or b>= b1) and
(a > a1 or b > b1 or c > c1)
order by a,b,c limit 1^ no offset necessary
confused yet?
This is interesting! Could you also
> > He's talking about this:
> > http://archives.postgresql.org/pgsql-performance/2004-07/msg00188.php
>
> Hmm...
>
> So the example would be that if you have just read a record from t
> that gave you value t.a=a1, t.b=b1, t.c=c1, the next one, based on
> a,b,c, would be...
>
> select * fro
> Josh Berkus writes:
>> It's esoteric enough that I don't know what you're talking about. Can
>> you give us an example?
>
> He's talking about this:
> http://archives.postgresql.org/pgsql-performance/2004-07/msg00188.php
Hmm...
So the example would be that if you have just read a record fr
Josh Berkus writes:
> It's esoteric enough that I don't know what you're talking about. Can
> you give us an example?
He's talking about this:
http://archives.postgresql.org/pgsql-performance/2004-07/msg00188.php
regards, tom lane
---(end of bro
Merlin Moncure <[EMAIL PROTECTED]> writes:
> Thanks for bringing the SQL 92 row constructor into spec for
> operations involving > and <. This is just fantastic.
Thought you'd like that ;-)
regards, tom lane
---(end of broadcast)--
Merlin,
Thanks for bringing the SQL 92 row constructor into spec for
operations involving > and <. This is just fantastic. I just
benchmarked ISAM style access to tables on multi-part keys and the
speedup is tremendous vs. the non row-constructor approach to the
problem which is tedius to write
Thanks for bringing the SQL 92 row constructor into spec for
operations involving > and <. This is just fantastic. I just
benchmarked ISAM style access to tables on multi-part keys and the
speedup is tremendous vs. the non row-constructor approach to the
problem which is tedius to write and only s
17 matches
Mail list logo
