date:20070208

Re: [BUGS] server crash: displaying sqlerrm in exception block

2007-02-08 Thread Tom Lane

"Asif Ali" <[EMAIL PROTECTED]> writes:
> your patch fixes the crash but instead of displaying the sqlerrm value, it
> is displaying  in
> pl block, declared inside exception block.

Hm, not what I see here.  Could you submit a test case that does that?

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [BUGS] server crash: displaying sqlerrm in exception block

2007-02-08 Thread Asif Ali


here is the test case


CREATE  OR REPLACE FUNCTION func() RETURNS int as $$
BEGIN
RAISE EXCEPTION 'ex -';
EXCEPTION
WHEN OTHERS THEN
RAISE INFO 'sql error msg %',sqlerrm;
DECLARE
v_msg VARCHAR(200) := sqlerrm;
BEGIN
RAISE INFO 'sql error msg %',sqlerrm;   -- it show's 
RAISE INFO 'sql error v_msg %',v_msg; -- it show's 
 ENd;
RETURN 0;
END;
$$ LANGUAGE plpgsql;


Regards,
--Asif

On 2/8/07, Tom Lane <[EMAIL PROTECTED]> wrote:


"Asif Ali" <[EMAIL PROTECTED]> writes:
> your patch fixes the crash but instead of displaying the sqlerrm value,
it
> is displaying  in
> pl block, declared inside exception block.

Hm, not what I see here.  Could you submit a test case that does that?

regards, tom lane





--
Regards,
--Asif Ali Rehman

Re: [BUGS] server crash: displaying sqlerrm in exception block

2007-02-08 Thread Tom Lane

"Asif Ali" <[EMAIL PROTECTED]> writes:
> here is the test case

It works for me:

regression=# select func();
INFO:  sql error msg ex -
INFO:  sql error msg ex -
INFO:  sql error v_msg ex -
 func
--
0
(1 row)

Are you sure you applied the patch correctly?  In particular, you'd need
a working version of bison to rebuild the gram.y file --- the behavior
you're reporting sounds like what would happen if that hadn't gotten
rebuilt.

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

[BUGS] Possible problem with type bigserial in pg_dump/pg_restore

2007-02-08 Thread Marcio A. Sepp


It seems to have a problem when making backup and restore with type
bigserial. I perceived when was restoring a database and the sequence
created for field bigserial was not correctly restored. 

For example, i've created the follow structure:

CREATE TABLE cager.princ
(
  cd_princ bigserial NOT NULL,
  nm_princ character varying(50),
  CONSTRAINT "pk-princ-cd_princ" PRIMARY KEY (cd_princ)
) 
WITHOUT OIDS;

Making backup with: 
C:\Arquivos de programas\pgAdmin III\1.6\pg_dump.exe -i -h 192.168.7.1 -p
5432 -U postgres -F c -b -v -f "C:\Temp\testepad.backup" testepad

Making restore with:
C:\Arquivos de programas\pgAdmin III\1.6\pg_restore.exe -i -h 192.168.7.1 -p
5432 -U postgres -d test1 -v "C:\Temp\testepad.backup"

The same table now is:

CREATE TABLE cager.princ
(
  cd_princ bigint NOT NULL DEFAULT nextval('princ_cd_princ_seq'::regclass),
  nm_princ character varying(50),
  CONSTRAINT "pk-princ-cd_princ" PRIMARY KEY (cd_princ)
) 
WITHOUT OIDS;

Take a look at the field cd_princ. Next value should be
'cager.princ_cd_princ_seq'.

I've tested it with pg_admin version 1.6.2 and 1.4.3.

If need more information, please, contact me.

Follow in annex messages on restoring.


 

Att.
Márcio A. Sepp
ZYON TECNOLOGIA LTDA
55 (49) 3444-4591
55 (49) 8405-9215

C:\Arquivos de programas\pgAdmin III\1.6\pg_restore.exe -i -h 192.168.7.1 -p 
5432 -U postgres -d test1 -v "C:\Temp\testepad.backup"
pg_restore: connecting to database for restore
pg_restore: [archiver (db)] Error while INITIALIZING:
pg_restore: [archiver (db)] could not execute query: ERROR:  parameter 
"standard_conforming_strings" cannot be changed
Command was: SET standard_conforming_strings = off;
pg_restore: creating SCHEMA cager
pg_restore: creating SCHEMA public
pg_restore: creating COMMENT SCHEMA public
pg_restore: creating TABLE princ
pg_restore: creating SEQUENCE princ_cd_princ_seq
pg_restore: creating SEQUENCE OWNED BY princ_cd_princ_seq
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 1514; 0 0 SEQUENCE OWNED BY 
princ_cd_princ_seq postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  syntax error at or 
near "OWNED"
LINE 1: ALTER SEQUENCE princ_cd_princ_seq OWNED BY princ.cd_princ;
  ^
Command was: ALTER SEQUENCE princ_cd_princ_seq OWNED BY princ.cd_princ;
pg_restore: executing SEQUENCE SET princ_cd_princ_seq
pg_restore: creating DEFAULT cd_princ
pg_restore: restoring data for table "princ"
pg_restore: creating CONSTRAINT pk-princ-cd_princ
pg_restore: setting owner and privileges for SCHEMA cager
pg_restore: setting owner and privileges for SCHEMA public
pg_restore: setting owner and privileges for COMMENT SCHEMA public
pg_restore: setting owner and privileges for ACL public
pg_restore: setting owner and privileges for TABLE princ
pg_restore: setting owner and privileges for SEQUENCE princ_cd_princ_seq
pg_restore: setting owner and privileges for SEQUENCE OWNED BY 
princ_cd_princ_seq
pg_restore: setting owner and privileges for DEFAULT cd_princ
pg_restore: setting owner and privileges for CONSTRAINT pk-princ-cd_princ
WARNING: errors ignored on restore: 2

Process returned exit code 1.

---(end of broadcast)---
TIP 1: 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

[BUGS] BUG #2974: broken CHECK constraint with varchar

2007-02-08 Thread Michal Schwarz


The following bug has been logged online:

Bug reference:  2974
Logged by:  Michal Schwarz
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.1.7
Operating system:   Fedora Core 6
Description:broken CHECK constraint with varchar
Details: 

CREATE TABLE t (c VARCHAR(20));
ALTER TABLE t ADD CONSTRAINT xyz CHECK (c IN ('A','B','C'));
INSERT INTO t VALUES ('A');

Results:
ERROR:  attribute 1 has wrong type
DETAIL:  Table has type character varying, but query expects character
varying.

In previous versions, everything worked correctly. Problem arised in 8.1.7
(maybe only in Fedora release???). When i returned back to 8.1.6, everything
worked again.

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

[BUGS] BUG #2980: check constraint fails on update

2007-02-08 Thread Walter Cruz


The following bug has been logged online:

Bug reference:  2980
Logged by:  Walter Cruz
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.1.7
Operating system:   Linux
Description:check constraint fails on update
Details: 

Hi All. A simple table to test:

CREATE TABLE simples
(
  coluna varchar(10)
) 
WITHOUT OIDS;

ALTER TABLE simples
  ADD CONSTRAINT simples_coluna_check CHECK (coluna::text = 'girafa'::text
OR coluna::text = 'bode'::text);

INSERT INTO simples (coluna) VALUES ('girafa');
(ok)

INSERT INTO simples (coluna) VALUES ('bode');
(ok)

INSERT INTO simples (coluna) VALUES ('macaco'); (violates constraints, ok).


UPDATE simples set coluna = 'girafa';

FAILS!

ERROR:  attribute 1 has wrong type
DETAIL:  Table has type character varying, but query expects character
varying.

"PostgreSQL 8.1.7 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.1.2
20061115 (prerelease) (Debian 4.1.1-21)"

Works with 8.1.3 windows, 8.1.4 ubuntu, 8.2 windows.

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

[BUGS] BUG #2981: server crash

2007-02-08 Thread Asif


The following bug has been logged online:

Bug reference:  2981
Logged by:  Asif
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.2.1
Operating system:   Fedora 3
Description:server crash
Details: 

I have compiled postgres 8.2.1 with gcc 4.1. and when executed this function
it crashes the server.

Steps to produce

CREATE  OR REPLACE FUNCTION func2() RETURNS int as $$
BEGIN
RAISE EXCEPTION 'ex -';
EXCEPTION
WHEN OTHERS THEN
RAISE INFO 'sql error msg %',sqlerrm;
DECLARE
v_msg VARCHAR(200) := sqlerrm;
BEGIN
RAISE INFO 'sql error msg %',sqlerrm;
  ENd;
RETURN 0;
END;
$$ LANGUAGE plpgsql;

select func2();


Output
--
INFO:  sql error msg ex -
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

---(end of broadcast)---
TIP 6: explain analyze is your friend

[BUGS] BUG #2975: UNIQUE INDEX doesn't work

2007-02-08 Thread Steven


The following bug has been logged online:

Bug reference:  2975
Logged by:  Steven
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system:   Windows Xp Sp2
Description:UNIQUE INDEX doesn't work
Details: 

I have a unique index on a table, but it is still possible to insert a
duplicated row, without any message what so ever.

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

[BUGS] BUG #2982: Install broken when not installed as a service

2007-02-08 Thread Dan Armbrust


The following bug has been logged online:

Bug reference:  2982
Logged by:  Dan Armbrust
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.2.3
Operating system:   Windows XP
Description:Install broken when not installed as a service
Details: 

If you try to install postgresql on windows XP, using the  msi installer,
and you choose to not install it as a service - when the install finishes -
it fails to run initdb.  If you try to run initdb manually, it results in a
message about "The program 'postgres' is needed by initdb but was not found
in
 the directory"...

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

[BUGS] ENC: Possible problem with type bigserial in pg_dump/pg_restore

2007-02-08 Thread Marcio A. Sepp


Pardon, in this example case it works ok. The problem is when i restore this
structure (this is my real case):

CREATE TABLE fat_m.ped_venda_it
(
  cd_ped_venda_it_record bigserial NOT NULL, 
  ...
  ...
)

When the table is created, the sequence is created too:
CREATE SEQUENCE fat_m.ped_venda_it_cd_ped_venda_it_record_seq

When i restore it, and try to insert a record the system show me the
message:
relation "ped_venda_it_cd_ped_venda_it_record" does not exist. 
Maybe the problem occurred because the name is too long. 

All the other sequence were restored fine.

Please, give me feedback about this problem. If i can help, i'll be
satisfied.


Att.
Márcio A. Sepp
ZYON TECNOLOGIA LTDA
(49) 3444-4591
(49) 8405-9215


> __ 
> De:   Marcio A. Sepp [mailto:[EMAIL PROTECTED] 
> Enviada em:   quarta-feira, 7 de fevereiro de 2007 12:51
> Para: 'pgsql-bugs@postgresql.org'
> Assunto:  Possible problem with type bigserial in pg_dump/pg_restore
> 
> 
> It seems to have a problem when making backup and restore with type
> bigserial. I perceived when was restoring a database and the sequence
> created for field bigserial was not correctly restored. 
> 
> For example, i've created the follow structure:
> 
> CREATE TABLE cager.princ
> (
>   cd_princ bigserial NOT NULL,
>   nm_princ character varying(50),
>   CONSTRAINT "pk-princ-cd_princ" PRIMARY KEY (cd_princ)
> ) 
> WITHOUT OIDS;
> 
> Making backup with: 
> C:\Arquivos de programas\pgAdmin III\1.6\pg_dump.exe -i -h 192.168.7.1 -p
> 5432 -U postgres -F c -b -v -f "C:\Temp\testepad.backup" testepad
> 
> Making restore with:
> C:\Arquivos de programas\pgAdmin III\1.6\pg_restore.exe -i -h 192.168.7.1
> -p 5432 -U postgres -d test1 -v "C:\Temp\testepad.backup"
> 
> The same table now is:
> 
> CREATE TABLE cager.princ
> (
>   cd_princ bigint NOT NULL DEFAULT
> nextval('princ_cd_princ_seq'::regclass),
>   nm_princ character varying(50),
>   CONSTRAINT "pk-princ-cd_princ" PRIMARY KEY (cd_princ)
> ) 
> WITHOUT OIDS;
> 
> Take a look at the field cd_princ. Next value should be
> 'cager.princ_cd_princ_seq'.
> 
> I've tested it with pg_admin version 1.6.2 and 1.4.3.
> 
> If need more information, please, contact me.
> 
> Follow in annex messages on restoring.
> 
> 
>  
> 
> Att.
> Márcio A. Sepp
> ZYON TECNOLOGIA LTDA
> 55 (49) 3444-4591
> 55 (49) 8405-9215
> 
C:\Arquivos de programas\pgAdmin III\1.6\pg_restore.exe -i -h 192.168.7.1 -p 
5432 -U postgres -d test1 -v "C:\Temp\testepad.backup"
pg_restore: connecting to database for restore
pg_restore: [archiver (db)] Error while INITIALIZING:
pg_restore: [archiver (db)] could not execute query: ERROR:  parameter 
"standard_conforming_strings" cannot be changed
Command was: SET standard_conforming_strings = off;
pg_restore: creating SCHEMA cager
pg_restore: creating SCHEMA public
pg_restore: creating COMMENT SCHEMA public
pg_restore: creating TABLE princ
pg_restore: creating SEQUENCE princ_cd_princ_seq
pg_restore: creating SEQUENCE OWNED BY princ_cd_princ_seq
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 1514; 0 0 SEQUENCE OWNED BY 
princ_cd_princ_seq postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  syntax error at or 
near "OWNED"
LINE 1: ALTER SEQUENCE princ_cd_princ_seq OWNED BY princ.cd_princ;
  ^
Command was: ALTER SEQUENCE princ_cd_princ_seq OWNED BY princ.cd_princ;
pg_restore: executing SEQUENCE SET princ_cd_princ_seq
pg_restore: creating DEFAULT cd_princ
pg_restore: restoring data for table "princ"
pg_restore: creating CONSTRAINT pk-princ-cd_princ
pg_restore: setting owner and privileges for SCHEMA cager
pg_restore: setting owner and privileges for SCHEMA public
pg_restore: setting owner and privileges for COMMENT SCHEMA public
pg_restore: setting owner and privileges for ACL public
pg_restore: setting owner and privileges for TABLE princ
pg_restore: setting owner and privileges for SEQUENCE princ_cd_princ_seq
pg_restore: setting owner and privileges for SEQUENCE OWNED BY 
princ_cd_princ_seq
pg_restore: setting owner and privileges for DEFAULT cd_princ
pg_restore: setting owner and privileges for CONSTRAINT pk-princ-cd_princ
WARNING: errors ignored on restore: 2

Process returned exit code 1.

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [BUGS] 8.2.2 regression with indices on user functions, 8.2.1 works

2007-02-08 Thread Tomas Szepe

> > Upgraded to 8.2.2 last night and had to revert to 8.2.1
> > first thing in the morning after hitting this problem:
> 
> Can you try your production case (not just a minimal example) with this
> patch?
> http://archives.postgresql.org/pgsql-committers/2007-02/msg00128.php

The patch didn't apply on top of vanilla 8.2.2, so I fetched the
current 8.2 CVS head - seems to work fine with our production db.

Thanks!

-- 
Tomas Szepe <[EMAIL PROTECTED]>

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

[BUGS] BUG #2979: Functional indexes ERROR while updating table

2007-02-08 Thread Roman Grigorovich


The following bug has been logged online:

Bug reference:  2979
Logged by:  Roman Grigorovich
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.1.7
Operating system:   FreeBSD 5.4-RELEASE
Description:Functional indexes ERROR while updating table
Details: 

create table test1 (name varchar(64));
create index test1_name_idx on test1(upper(name));
insert into test1 values ('test');
update test1 set name = 'test1';

ERROR:  attribute 1 has wrong type
DETAIL:  Table has type character varying, but query expects character
varying.

What is it? On version 8.1.2 - ALL OK!

Detail of config:
bash-3.00# ./pg_config
BINDIR = /usr/local/postgres/bin
DOCDIR =
INCLUDEDIR = /usr/local/postgres/include
PKGINCLUDEDIR = /usr/local/postgres/include
INCLUDEDIR-SERVER = /usr/local/postgres/include/server
LIBDIR = /usr/local/postgres/lib
PKGLIBDIR = /usr/local/postgres/lib
LOCALEDIR = /usr/local/postgres/share/locale
MANDIR = /usr/local/postgres/man
SHAREDIR = /usr/local/postgres/share
SYSCONFDIR = /usr/local/postgres/etc
PGXS = /usr/local/postgres/lib/pgxs/src/makefiles/pgxs.mk
CONFIGURE = '--prefix=/usr/local/postgres' '--without-docdir' '--enable-nls'
'--cache-file=/dev/null' 'CPPFLAGS=-I/usr/local/include'
'LDFLAGS=-L/usr/local/lib'
CC = gcc
CPPFLAGS = -I/usr/local/include
CFLAGS = -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing
CFLAGS_SL = -fPIC -DPIC
LDFLAGS = -L/usr/local/lib -Wl,-R/usr/local/postgres/lib
LDFLAGS_SL =
LIBS = -lpgport -lintl -lz -lreadline -lcrypt -lcompat -lm -lutil
VERSION = PostgreSQL 8.1.7

Cluster info:
LC_COLLATE: ru_RU.UTF-8
LC_CTYPE: ru_RU.UTF-8

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [BUGS] BUG #2979: Functional indexes ERROR while updating table

2007-02-08 Thread Guillaume Smet


Roman,

On 2/7/07, Roman Grigorovich <[EMAIL PROTECTED]> wrote:

ERROR:  attribute 1 has wrong type
DETAIL:  Table has type character varying, but query expects character
varying.

What is it? On version 8.1.2 - ALL OK!


This is a known problem of 8.1.7. That's why 8.1.8 has been released.

So you should upgrade to 8.1.8 to fix your problem.

--
Guillaume

---(end of broadcast)---
TIP 1: 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] BUG #2980: check constraint fails on update

2007-02-08 Thread Heikki Linnakangas

This is a known issue with 8.1.7. 8.1.8 was released shortly after 8.1.7 
 because of this.


Walter Cruz wrote:
-> The following bug has been logged online:


Bug reference:  2980
Logged by:  Walter Cruz
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.1.7
Operating system:   Linux
Description:check constraint fails on update
Details: 


Hi All. A simple table to test:

CREATE TABLE simples
(
  coluna varchar(10)
) 
WITHOUT OIDS;


ALTER TABLE simples
  ADD CONSTRAINT simples_coluna_check CHECK (coluna::text = 'girafa'::text
OR coluna::text = 'bode'::text);

INSERT INTO simples (coluna) VALUES ('girafa');
(ok)

INSERT INTO simples (coluna) VALUES ('bode');
(ok)

INSERT INTO simples (coluna) VALUES ('macaco'); (violates constraints, ok).


UPDATE simples set coluna = 'girafa';

FAILS!

ERROR:  attribute 1 has wrong type
DETAIL:  Table has type character varying, but query expects character
varying.

"PostgreSQL 8.1.7 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.1.2
20061115 (prerelease) (Debian 4.1.1-21)"

Works with 8.1.3 windows, 8.1.4 ubuntu, 8.2 windows.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [BUGS] Possible problem with type bigserial in pg_dump/pg_restore

2007-02-08 Thread Tom Lane

"Marcio A. Sepp" <[EMAIL PROTECTED]> writes:
> It seems to have a problem when making backup and restore with type
> bigserial.

Don't use a pg_dump/pg_restore that are newer than your server version.

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [BUGS] BUG #2974: broken CHECK constraint with varchar

2007-02-08 Thread Bruce Momjian

Michal Schwarz wrote:
> 
> The following bug has been logged online:
> 
> Bug reference:  2974
> Logged by:  Michal Schwarz
> Email address:  [EMAIL PROTECTED]
> PostgreSQL version: 8.1.7
> Operating system:   Fedora Core 6
> Description:broken CHECK constraint with varchar
> Details: 
> 
> CREATE TABLE t (c VARCHAR(20));
> ALTER TABLE t ADD CONSTRAINT xyz CHECK (c IN ('A','B','C'));
> INSERT INTO t VALUES ('A');
> 
> Results:
> ERROR:  attribute 1 has wrong type
> DETAIL:  Table has type character varying, but query expects character
> varying.
> 
> In previous versions, everything worked correctly. Problem arised in 8.1.7
> (maybe only in Fedora release???). When i returned back to 8.1.6, everything
> worked again.

Please upgrade to 8.1.8.  That was a rush release to fix this bug added
in 8.1.7.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [BUGS] BUG #2975: UNIQUE INDEX doesn't work

2007-02-08 Thread Bruce Momjian

Steven wrote:
> 
> The following bug has been logged online:
> 
> Bug reference:  2975
> Logged by:  Steven
> Email address:  [EMAIL PROTECTED]
> PostgreSQL version: 8.1.4
> Operating system:   Windows Xp Sp2
> Description:UNIQUE INDEX doesn't work
> Details: 
> 
> I have a unique index on a table, but it is still possible to insert a
> duplicated row, without any message what so ever.

Please show us a self-contained example.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [BUGS] server crash: displaying sqlerrm in exception block

2007-02-08 Thread Asif Ali


Hi,
well i just updated the code and found your patch is applied in there and
it's working. may be i missed something while applying your patch.

Regards,
--Asif

On 2/8/07, Tom Lane <[EMAIL PROTECTED]> wrote:


"Asif Ali" <[EMAIL PROTECTED]> writes:
> here is the test case

It works for me:

regression=# select func();
INFO:  sql error msg ex -
INFO:  sql error msg ex -
INFO:  sql error v_msg ex -
func
--
0
(1 row)

Are you sure you applied the patch correctly?  In particular, you'd need
a working version of bison to rebuild the gram.y file --- the behavior
you're reporting sounds like what would happen if that hadn't gotten
rebuilt.

regards, tom lane





--
Regards,
--Asif Ali Rehman

Re: [BUGS] server crash: displaying sqlerrm in exception block

Re: [BUGS] server crash: displaying sqlerrm in exception block

Re: [BUGS] server crash: displaying sqlerrm in exception block

[BUGS] Possible problem with type bigserial in pg_dump/pg_restore

[BUGS] BUG #2974: broken CHECK constraint with varchar

[BUGS] BUG #2980: check constraint fails on update

[BUGS] BUG #2981: server crash

[BUGS] BUG #2975: UNIQUE INDEX doesn't work

[BUGS] BUG #2982: Install broken when not installed as a service

[BUGS] ENC: Possible problem with type bigserial in pg_dump/pg_restore

Re: [BUGS] 8.2.2 regression with indices on user functions, 8.2.1 works

[BUGS] BUG #2979: Functional indexes ERROR while updating table

Re: [BUGS] BUG #2979: Functional indexes ERROR while updating table

Re: [BUGS] BUG #2980: check constraint fails on update

Re: [BUGS] Possible problem with type bigserial in pg_dump/pg_restore

Re: [BUGS] BUG #2974: broken CHECK constraint with varchar

Re: [BUGS] BUG #2975: UNIQUE INDEX doesn't work

Re: [BUGS] server crash: displaying sqlerrm in exception block

18 matches

Site Navigation

Mail list logo

Footer information