Re: [BUGS] BUG #1015: Got a signal 11 while trying to create a temp table

How do I get a "debugger backtrace" ?Selecting all data from the tables involved, does that also include a 'count(*)', if so, they work:stats=# select count(*) from blocks;  count- 3194409(1 row)stats=# select count(*) from hosts; count---   205(1 row)stats=#Yours,Aarjan- O

[BUGS] BUG #1016: incomplete src/bin/pgtclsh/Makefile

The following bug has been logged online: Bug reference: 1016 Logged by: Patrick Samson Email address: [EMAIL PROTECTED] PostgreSQL version: 7.3.5 Operating system: Cygwin Description:incomplete src/bin/pgtclsh/Makefile Details: "make install" fails on cygwin for pg

[BUGS] BUG #1017: Incomplete src/interfaces/libpgtcl/Makefile

The following bug has been logged online: Bug reference: 1017 Logged by: Patrick Samson Email address: [EMAIL PROTECTED] PostgreSQL version: 7.3.5 Operating system: Cygwin Description:Incomplete src/interfaces/libpgtcl/Makefile Details: For "configure --with-tcl --w

[BUGS] BUG #1018: Incomplete src/pl/tcl/Makefile

The following bug has been logged online: Bug reference: 1018 Logged by: Patrick Samson Email address: [EMAIL PROTECTED] PostgreSQL version: 7.3.5 Operating system: Cygwin Description:Incomplete src/pl/tcl/Makefile Details: For "configure --with-tcl --without-tk". '

[BUGS] BUG #1019: src/pl/tcl/pltcl.c

The following bug has been logged online: Bug reference: 1019 Logged by: Patrick Samson Email address: [EMAIL PROTECTED] PostgreSQL version: 7.3.5 Operating system: Cygwin Description:src/pl/tcl/pltcl.c Details: For "configure --with-tcl --without-tk". 'make' doesn'

Re: [BUGS] BUG #1016: incomplete src/bin/pgtclsh/Makefile

> "make install" fails on cygwin for pgtclsh: > > in src/bin/pgtclsh/Makefile, add $(X) to the end of every occurrence of > 'pgtclsh' and 'pgtksh' as part of a command. > > Example: > $(INSTALL_PROGRAM) pgtclsh$(X) $(DESTDIR)$(bindir)/pgtclsh$(X) Fixed. ---(end of broadca

Re: [BUGS] BUG #1017: Incomplete src/interfaces/libpgtcl/Makefile

> In src/interfaces/libpgtcl/Makefile: > Change: > SHLIB_LINK = $(libpq) > To: > SHLIB_LINK = $(TCL_LIB_SPEC) $(libpq) This is already fixed in 7.4. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate

Re: [BUGS] BUG #1018: Incomplete src/pl/tcl/Makefile

> In src/pl/tcl/Makefile: > Change: > # link command for a shared lib must NOT mention shared libs it uses > SHLIB_LINK = $(TCL_LIB_SPEC) > To: > # link command for a shared lib must NOT mention shared libs it uses > SHLIB_LINK = $(BE_DLLLIBS) $(TCL_LIB_SPEC) This is already fixed in 7.4. --

[BUGS] CASE in where statement. BUG ??

I belive that I have found a bug - or maybe it was done on purpose. Have a look at this query: SELECT integer_field FROM bugtable WHERE (CASE WHEN '' <> '' THEN integer_field = '' ELSE integer_field = 0 END); Result: ERROR: invalid input syntax for integer: "" SELECT text_field FROM bugtable W

Re: [BUGS] [GENERAL] CASE in where statement. BUG ??

Alexander Litvinov wrote: This is normaol behavior. I belive that I have found a bug - or maybe it was done on purpose. Have a look at this query: SELECT integer_field FROM bugtable WHERE (CASE WHEN '' <> '' THEN integer_field = '' ELSE integer_field = 0 END); Result: ERROR: invalid input syntax

Re: [BUGS] [GENERAL] CASE in where statement. BUG ??

On Friday 19 December 2003 09:02, Marek Lewczuk wrote: > Alexander Litvinov wrote: > > This is normaol behavior. > > > >>I belive that I have found a bug - or maybe it was done on purpose. Have > >>a look at this query: > >> > >> > >>SELECT integer_field FROM bugtable WHERE (CASE WHEN '' <> '' THEN

Re: [BUGS] [GENERAL] CASE in where statement. BUG ??

Richard Huxton wrote: On Friday 19 December 2003 09:02, Marek Lewczuk wrote: But until it's evaluated ''<>'' it doesn't know it is false. When building the CASE expression, it's trying to map types to each elements and notes that '' is not an int. Only after this stage will it actually try to ev

Re: [BUGS] [GENERAL] CASE in where statement. BUG ??

Csaba Nagy wrote: Because that's a syntax check, which does NOT evaluate any of the expressions, only the types of them. Even if it will not be executed ever, it is still wrong, and it should generate an error, because it means a mistake on your side which potentially could leave to results you did

Re: [BUGS] BUG #1019: src/pl/tcl/pltcl.c

> In src/pl/tcl/pltcl.c: > Permute the order of: > #include "postgres.h" > #include > so as it appears as: > #include > #include "postgres.h" I' afraid this is not a fix but just paints over the symptoms. As you noticed, this topic has already been discussed, and the solution needs to be

Re: [BUGS] Urgent: Key constraints behaving weirdly

Tom Lane wrote: > "Russell Garrett" <[EMAIL PROTECTED]> writes: >> last=> reindex index profile_pkey; >> ERROR: could not create unique index >> DETAIL: Table contains duplicated values. > > Okay, it looks like the table actually contains duplicate rows but the > index has managed to lose track o

Re: [BUGS] plpgsql Integer Concat To String

Convert "counter" into a VARCHAR and coincatinate that to IdSet using th || operator. You cannot concatinate data of differing TYPEs. Rick Puneet Paul wrote: Hi, I want to concatenate a it counter to a string in a loop in plpgsql. DECLARE counter integer := 1; IdSet char : = 'UniqueId' IdForE

[BUGS] BUG #1020: Timestamp representation printed by PostgreSQL are invalid

The following bug has been logged online: Bug reference: 1020 Logged by: Sebastiano Vigna Email address: [EMAIL PROTECTED] PostgreSQL version: 7.3.4 Operating system: Linux Description:Timestamp representation printed by PostgreSQL are invalid Details: create table

Re: [BUGS] BUG #1019: src/pl/tcl/pltcl.c

Peter Eisentraut <[EMAIL PROTECTED]> writes: >> In src/pl/tcl/pltcl.c: >> Permute the order of: >> #include "postgres.h" >> #include >> so as it appears as: >> #include >> #include "postgres.h" > I' afraid this is not a fix but just paints over the symptoms. ... and would create serious new pro

Re: [BUGS] BUG #1020: Timestamp representation printed by PostgreSQL are invalid

"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > This is nonsense: the representation returned by a SELECT for a data type should be > *VALID*, shouldn't it? CURRENT_TIME delivers a timetz value, which is not the same datatype as time. Having said that, 7.4 will accept this input string for

[BUGS] ecpg c++ scope operator lost

Ecpg pretty prints my code causing compile errors. ie. code to compile: EXEC SQL BEGIN DECLARE SECTION; char bound_waiting_state = static_cast(Processor::waiting); EXEC SQL END DECLARE SECTION; turns into: /* exec sql begin declare section */ #line 90 "Schedule.pgcc" char bo

[BUGS] Bug in make (informix?)

See attachment. Regards Oli --- Oli Sennhauser Database-Engineer (Oracle & PostgreSQL) Rebenweg 6 CH - 8610 Uster / Switzerland Phone (+41) 1 940 24 82 or Mobile (+41) 79 450 49 14 e-Mail [EMAIL PROTECTED] Website http://mypage.bluewin.ch/shing

[BUGS] hpux 11.11 initdb error

HP-UX 11.11 PostgreSQL Version 7.4 installation to non default location ./configure --prefix=/usr/local/pgsql74 After make and instalation which appears to have worked, the initdb process fails with the following. creating conversions... ERROR: could not access file "$libdir/ascii_and_mic":

[BUGS] Jdbc connection pooling and PG 7.4 consistently fails

Hi   Having downloaded and installed the rpms for 7.4 I upgraded the database and began testing. As the system under development is based on servlets we are using the JDBC3 Jdbc3PoolingDataSource to provide the connections. All attempts to read from the database via jdbc pooled connections n

[BUGS] 7.1.3 ecpg answered BUT...

In more research in this problem I found that if the EXEC SQL OPEN cursor; command was not present that ecpg would just comment out the cusrsor declare statements. Might I make a suggestion that the software designers make a rule to give some kind of notice at compile time (rather than only an er

Re: [BUGS] BUG #1011: Explain analyze "query" cause segv

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Dec 17, 2003 at 03:18:06PM -0500, Tom Lane wrote: > > There is test case (notice there is ltree column): > Seems to be a buffer overrun in lquery_out(). I've applied the attached > patch for 7.4.1. That patch solved problem. Thanks Tom ! Reg

[BUGS] Bugs in bigint indexes

Title: Message Dear developers,   I almost got nuts those two days I'm stuck with this issue... Let's get straight to the point. I'm using a small portion of my actual table, but this is enough.   CREATE SEQUENCE it_seq;CREATE TABLE it_test ( id   bigint not null primary key default nex

[BUGS] plpgsql

Hi, I want to concatenate a it counter to a string in a loop in plpgsql. DECLARE counter integer := 1; IdSet char : = 'UniqueId' IdForEachRun varchar; BEGIN IdForEachRun := IdSet || counter;(PROBLEM HERE) --Or IdForEachRun := IdSet + counter;(PROBLEM HERE) While condition LOOP Insert into Table

[BUGS] BUG #1021: IDENT authorization doesn't work

The following bug has been logged online: Bug reference: 1021 Logged by: alexeyof Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4 Operating system: FreeBSD 4.9-STABLE Description:IDENT authorization doesn't work Details: OS: FreeBSD 4.9-STABLE PG: PostgreSQ

Re: [BUGS] Bugs in bigint indexes

Gustavo Scotti writes: > when the key is bigint, it ignores any kind of index scan, it always use > Seq scan. Why? RTFM: http://www.postgresql.org/docs/7.4/static/datatype.html#DATATYPE-INT Please don't post to pgsql-bugs unless you have found a bug. ---(end of broadcast

Re: [BUGS] 7.1.3 ecpg answered BUT...

[EMAIL PROTECTED] writes: > In more research in this problem I found that if the > EXEC SQL OPEN cursor; command was not present that > ecpg would just comment out the cusrsor declare statements. Please use a recent version and give us a reproduceable example if you expect any kind of feedback.

[BUGS] Please take me out of this emailing list. Thank you very much!

---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly

Re: [BUGS] hpux 11.11 initdb error

"Ed Stouder" <[EMAIL PROTECTED]> writes: > Based on some simple testing it appears initdb is looking for the files in > the default location not the prefix location. I don't think so. Nondefault --prefix is actually the standard configuration for me and most of the other developers; I can assure

Re: [BUGS] Bugs in bigint indexes

On Wed, 17 Dec 2003, Gustavo Scotti wrote: > > _ > > > Dear developers, > > I almost got nuts those two days I'm stuck with this issue... > Let's get straight to the point. I'm using a small portion of my actual > table, but this is enough.

Re: [BUGS] Jdbc connection pooling and PG 7.4 consistently fails

On Thu, 18 Dec 2003, Lewis Foti wrote: > Hi > > Having downloaded and installed the rpms for 7.4 I upgraded the database and > began testing. As the system under development is based on servlets we are > using the JDBC3 Jdbc3PoolingDataSource to provide the connections. All > attempts to read fro

Re: [BUGS] Bugs in bigint indexes

Nishad Prakash <[EMAIL PROTECTED]> writes: > Why doesn't the query planner notice that an int-type index is present > and perform the cast on its own? Perhaps one of the developers > can explain? I think users would like this property if it could be > implemented without breaking anything. It's

Re: [BUGS] [GENERAL] CASE in where statement. BUG ??

Marek Lewczuk <[EMAIL PROTECTED]> writes: > Well, I must say that it is wird action... Why to check both elements of > CASE expression, if we know for sure that only one will be executed ? It cannot discover that the WHEN clause is constant-false until after it has performed syntactic analysis --

Re: [BUGS] [GENERAL] CASE in where statement. BUG ??

This is normaol behavior. > I belive that I have found a bug - or maybe it was done on purpose. Have > a look at this query: > > > SELECT integer_field FROM bugtable WHERE (CASE WHEN '' <> '' THEN > integer_field = '' ELSE integer_field = 0 END); > Result: ERROR: invalid input syntax for integer:

Re: [BUGS] [GENERAL] CASE in where statement. BUG ??

> Well, I must say that it is wird action... Why to check both elements of > CASE expression, if we know for sure that only one will be executed ? Because that's a syntax check, which does NOT evaluate any of the expressions, only the types of them. Even if it will not be executed ever, it is sti

Re: [BUGS] Bugs in bigint indexes

Title: Message Try this    explain SELECT id FROM it_test WHERE id='123'; QUERY PLAN Index Scan using it_test_pkey on it_test  (cost=0.00..4.82 rows=1 width=8)   Index Cond: (id = 123

Re: [BUGS] Bug in make (informix?)

On Wed, Dec 17, 2003 at 04:42:25PM +0100, Oli Sennhauser wrote: > The make with the follwing flag causes an error. Without flag runs without problems. > This seems to be a bug of 7.4 because 7.3.5 was running fine with this flag. > > make CPPFLAGS=-DALLOW_ABSOLUTE_DBPATHS allo > ... This actually

Re: [BUGS] ecpg c++ scope operator lost

On Wed, Dec 17, 2003 at 03:14:31PM -0500, Mark Pether wrote: > Ecpg pretty prints my code causing compile errors. Please note that ecpg is a precompiler for embedded SQL in C not C++. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber:

Re: [BUGS] Jdbc connection pooling and PG 7.4 consistently fails

On Friday 19 December 2003 01:27 pm, Kris Jurka wrote: > The RPMs do not have the correct jar file. Try one of those available > from http://jdbc.postgresql.org/download.html At the time I put the RPMs together there were no 'stable' 7.4 jars, so I grabbed the dev jars and the 7.3 jars and packa

Re: [BUGS] dyntest.pgc not working in 7.4 ?

On Fri, Dec 12, 2003 at 01:07:01AM -0600, Seum-Lim Gan wrote: > Hi Michael, > > Looks like the libecpg we are using is 4.0. > > Any idea ? Please run the program against an empty database and the pg_tables table and see what happens then. Also could you please send me the file "log" dyntext prod

Re: [BUGS] Jdbc connection pooling and PG 7.4 consistently fails

On Fri, 19 Dec 2003, Lamar Owen wrote: > On Friday 19 December 2003 01:27 pm, Kris Jurka wrote: > > The RPMs do not have the correct jar file. Try one of those available > > from http://jdbc.postgresql.org/download.html > > At the time I put the RPMs together there were no 'stable' 7.4 jars, so

Re: [BUGS] Jdbc connection pooling and PG 7.4 consistently fails

On Friday 19 December 2003 04:11 pm, Kris Jurka wrote: > On Fri, 19 Dec 2003, Lamar Owen wrote: > > On Friday 19 December 2003 01:27 pm, Kris Jurka wrote: > > > The RPMs do not have the correct jar file. Try one of those available > > > from http://jdbc.postgresql.org/download.html > > At the tim

Re: [BUGS] pg_service.conf ignores dbname parameter

I have applied the attached patch to remove the default dbname=serive-name code, changed the comment at the top of the file, and changed a few ints to booleans. --- Michael Fuhr wrote: > =

[BUGS] BUG #1022: date calculation forces wrong type in function parameter and causes error

The following bug has been logged online: Bug reference: 1022 Logged by: Bruce Patin Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4 Operating system: FreeBSD 4.8-RELEASE Description:date calculation forces wrong type in function parameter and causes error D

Re: [BUGS] Jdbc connection pooling and PG 7.4 consistently fails

On Fri, 19 Dec 2003, Lamar Owen wrote: > > While I've got your attention on this, where is a good place for the RPM to > place the jars that would be usable by the largest number of people? > Currently they are just plunked down and no real installation is being done. > > Or, to put it a differe

Re: [BUGS] 7.1.3 ecpg answered BUT...

May I aks you why you sent he same topic with different emails to -bugs and to -general without even giving us a chance to answer? It has not been a cross-post, so I fail to see the reasoning. Anyway .. On Fri, Dec 19, 2003 at 09:58:05AM -0700, [EMAIL PROTECTED] wrote: > In more research in this p

Re: [BUGS] pg_service.conf ignores dbname parameter

Bruce Momjian <[EMAIL PROTECTED]> writes: > I have applied the attached patch to remove the default > dbname=serive-name code, changed the comment at the top of the file, and > changed a few ints to booleans. Looks good, but you should apply to 7.4 branch as well. The argument that we can change

Re: [BUGS] pg_service.conf ignores dbname parameter

Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I have applied the attached patch to remove the default > > dbname=serive-name code, changed the comment at the top of the file, and > > changed a few ints to booleans. > > Looks good, but you should apply to 7.4 branch as well. The

Re: [BUGS] BUG #1022: date calculation forces wrong type in function parameter and causes error

"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > In Pg 7.3 and before, I have successfully used a function with a date parameter such > as this simplified version: Perhaps this worked in 7.2 and before, before we tightened the implicit-casting rules. It does not work in 7.3. > CREATE FUNCTI