Greg Sabino Mullane writes:
> Can the configure script be made to check for a proper version of bison?
Normally the parser files are prebuild and bison is never invoked. So it
seems wasteful to do a bunch of checking for this rare case.
--
Peter Eisentraut [EMAIL PROTECTED]
---
CREATE TABLE foo ("key" int4 NOT NULL, "data1"
varchar(20), "data2" varchar(20));
INSERT INTO foo VALUES ('1','zzz');
SELECT * FROM foo ;
key | data1 | data2
-+---+---
1 | zzz |
(1 row)
SELECT key || '|' || data1 || '|' || data2 FROM foo;
?column?
--
(1 row)
If data1
Andres Cuevas wrote:
If data1 or data2 are NULL the request is NULL
Which is the correct behavior, not a bug. See:
http://techdocs.postgresql.org/guides/BriefGuideToNulls
HTH,
Joe
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ
Tom Lane wrote:
Dmitry Tkach <[EMAIL PROTECTED]> writes:
explain select * from abc where a=1 and b in (1,2);
Now, why doesn't it want to use the index for the second condition???
Because the expression preprocessor prefers CNF (AND of ORs) over
DNF (OR of ANDs). Since your WHERE clause is alre
Dmitry Tkach writes:
> explain select * from abc where a=1 and b in (1,2);
>
> QUERY PLAN
> -
> Index Scan using abc_idx on abc (cost=0.00..17.09 rows=1 width=12)
>Index Cond: (a = 1)
>Filter
Dmitry Tkach <[EMAIL PROTECTED]> writes:
> explain select * from abc where a=1 and b in (1,2);
> Now, why doesn't it want to use the index for the second condition???
Because the expression preprocessor prefers CNF (AND of ORs) over
DNF (OR of ANDs). Since your WHERE clause is already CNF, it wo
Hello.
We had a very serious trouble last week with our databases in Postgres and we
wanna know if maybe someone can help us to find the problem.
The trouble was that a day some databases in Postgres appear without any row
of information; some other, doesn't led us describe the tables (\d), o