Uh, have we addressed this? I don't think so.
---
Heikki Linnakangas wrote:
On 02.04.2011 20:48, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
We sometimes transform IN-clauses to a
Nope, this hasn't been addressed. FWIW, I put it on the todo list when I
stopped working on it.
On 06.09.2011 20:48, Bruce Momjian wrote:
Uh, have we addressed this? I don't think so.
---
Heikki Linnakangas wrote:
On
Heikki Linnakangas wrote:
Nope, this hasn't been addressed. FWIW, I put it on the todo list when I
stopped working on it.
Oh, I see it now. Thanks.
---
On 06.09.2011 20:48, Bruce Momjian wrote:
Uh, have we
Bruce Momjian br...@momjian.us writes:
Uh, have we addressed this? I don't think so.
No. IIRC, I didn't like Heikki's proposed patch, so it's on my head
to come up with something better.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Uh, have we addressed this? I don't think so.
No. IIRC, I didn't like Heikki's proposed patch, so it's on my head
to come up with something better.
You can blame me for getting it into the parser. It used to be in
gram.y!
--
On 06.09.2011 20:53, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjianbr...@momjian.us writes:
Uh, have we addressed this? I don't think so.
No. IIRC, I didn't like Heikki's proposed patch, so it's on my head
to come up with something better.
You can blame me for getting it into the
Heikki Linnakangas wrote:
On 06.09.2011 20:53, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjianbr...@momjian.us writes:
Uh, have we addressed this? I don't think so.
No. IIRC, I didn't like Heikki's proposed patch, so it's on my head
to come up with something better.
You can
On 11.04.2011 19:33, Heikki Linnakangas wrote:
On 11.04.2011 19:06, Kevin Grittner wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com wrote:
Hmm, the SQL specification explicitly says that
X BETWEEN Y AND Z
is equal to
X= Y AND X= Z
It doesn't say anything about side-effects of
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I'd like us to still fix this so that there's no multiple evaluation -
that would actually make BETWEEN more useful than it is today. I'm
working on a patch to handle both BETWEEN and IN.
One other issue here is that the parser
On 05.04.2011 18:42, Heikki Linnakangas wrote:
On 05.04.2011 13:19, Marti Raudsepp wrote:
On Fri, Apr 1, 2011 at 14:24, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
We sometimes transform IN-clauses to a list of ORs:
postgres=# explain SELECT * FROM foo WHERE a IN (b, c);
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
On 05.04.2011 18:42, Heikki Linnakangas wrote:
On 05.04.2011 13:19, Marti Raudsepp wrote:
On Fri, Apr 1, 2011 at 14:24, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
We sometimes transform IN-clauses to a list of
On 11.04.2011 19:06, Kevin Grittner wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com wrote:
On 05.04.2011 18:42, Heikki Linnakangas wrote:
On 05.04.2011 13:19, Marti Raudsepp wrote:
On Fri, Apr 1, 2011 at 14:24, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
We
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Does anyone object to making BETWEEN and IN more strict about the data
types? At the moment, you can do this:
postgres=# SELECT '1234' BETWEEN '10001'::text AND 10002::int4;
?column?
--
t
(1 row)
I'm thinking
On Fri, Apr 1, 2011 at 14:24, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
We sometimes transform IN-clauses to a list of ORs:
postgres=# explain SELECT * FROM foo WHERE a IN (b, c);
QUERY PLAN
Seq Scan on foo (cost=0.00..39.10 rows=19 width=12)
On 05.04.2011 13:19, Marti Raudsepp wrote:
On Fri, Apr 1, 2011 at 14:24, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
We sometimes transform IN-clauses to a list of ORs:
postgres=# explain SELECT * FROM foo WHERE a IN (b, c);
QUERY PLAN
Seq Scan on foo
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
We sometimes transform IN-clauses to a list of ORs:
postgres=# explain SELECT * FROM foo WHERE a IN (b, c);
QUERY PLAN
--
Seq Scan on foo
We sometimes transform IN-clauses to a list of ORs:
postgres=# explain SELECT * FROM foo WHERE a IN (b, c);
QUERY PLAN
--
Seq Scan on foo (cost=0.00..39.10 rows=19 width=12)
Filter: ((a = b) OR (a = c))
(2 rows)
But
On Fri, Apr 01, 2011 at 02:24:53PM +0300, Heikki Linnakangas wrote:
I tried to read the SQL spec to see if it has anything to say about
that, but I couldn't find anything. My common sense says that that
transformation is not legal.
Your feeling is correct; I would motivate it as follows.
On Fri, Apr 1, 2011 at 7:24 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
My common sense says that that transformation
is not legal.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list
19 matches
Mail list logo
