Re: [GENERAL] A rare error

DaVinci <[EMAIL PROTECTED]> writes: > An extrange behavior with PostgreSql 7.0.2: > select * from foo where exists > (select * from foo) > works fine. But: > select * from foo where exists > ((select * from foo)) > shows an error: > ERROR: parser: parse error at or ne

Re: [GENERAL] Re: PL/Perl compilation error

Hi, Do you use the file GNUmakefile and ppport.h I recently send to the list ? What is your version of Perl ? Could you send me output of your build ? Regards, Gilles DAROLD Larry Rosenman wrote: > Broke my build on UnixWare 7.1.1... May be perl version confusion... > > See my post to -hacke

Re: [GENERAL] latest version?

Pawel Wegrzyn wrote: > > Hi, > What is the latest version of PostgreSQL? > Is there something like 7.1? The most recent version 7.0.2. 7.1 is about to come - I am looking forward to it as well. Regards, Mit freundlichem Gruß, Holger Klawitter -- Holger Klawitter

Re: [GENERAL] index problems

Brook Milligan wrote: > I am getting the following messages when I VACUUM ANALYZE: > > NOTICE: Index pg_attribute_relid_attnum_index: NUMBER OF INDEX' TUPLES (3579) IS >NOT THE SAME AS HEAP' (4517). > Recreate the index. > NOTICE: Index pg_attribute_relid_attnam_index: NUMBER OF INDEX

Re: [GENERAL] Delete temp tables

: In short: if you want to delete a table there is one and only one : safe method to do it: DROP TABLE. The key difference between a temp : table and a regular table is that the DROP will be done for you : automatically when you disconnect. Now why? relatorio=# DROP TABLE "pg_temp.1823.17"; ERR

[GENERAL] Can I deactivate indexes?

Question is: I want to use key words like SERIAL, PRIMARY KEY, etc, for creating tables, but this words create indexes asociated to tables. If i use COPY to poblate tables, indexes make tranfer very slow. How can i deactivate indexes temporaly for making a COPY?. Any other strategy?. Thanks f

[GENERAL] A rare error

Hi, all. An extrange behavior with PostgreSql 7.0.2: select * from foo where exists (select * from foo) works fine. But: select * from foo where exists ((select * from foo)) shows an error: ERROR: parser: parse error at or near "(" Is this a bug? Tha

[GENERAL] [OT] Is there any site with list archives?

I'd like consulting past messages. Greets. David

Re: [GENERAL] Problems with genetic optimizer

Peter Keller <[EMAIL PROTECTED]> writes: > Ok, I created a table with only one column (box), inserted 12 > elements, created an index and run a vacuum: > convert=# explain select * from box_tmp where ebre && > box('(470758.555,354028.145),(470758.525,354028.115)'::box); > NOTICE: QUERY PLAN:

Re: [GENERAL] Problems with genetic optimizer

> > The result of the query if I set the sequential search on is this: > > > convert=# select * from box_tmp where ebre && > > box('(470758.555,354028.145),(470758.525,354028.115)'::box); > > pqReadData() -- backend closed the channel unexpectedly. > > Urk. That's not supposed to happen. There

Re: [GENERAL] newbie debugging pl/pgsql : better way?

Ashley Clark <[EMAIL PROTECTED]> writes: >> Is there a better way to debug pl/pgsql functions? > If you find it let me know. The postmaster log should have useful tidbits. Make sure there *is* a postmaster log --- start the postmaster without -S, and with its stdout and stderr directed into a l