[BUGS] BUG #1329: Bug in IF-ELSEIF-ELSE construct
The following bug has been logged online: Bug reference: 1329 Logged by: Rico Wind Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Beta Operating system: Windows XP, SP2 Description:Bug in IF-ELSEIF-ELSE construct Details: Beta 1. The following always returns 4: IF from_date_param=period_begin AND until_date_param=period_end THEN return 1; ELSEIF from_date_param=period_begin THEN return 2; ELSEIF until_date_param=period_end THEN return 3; ELSE return 4; END IF; Whereas the following returns the right answer(not 4 each time). They should be the same. IF from_date_param=period_begin AND until_date_param=period_end THEN return 1; ELSE IF from_date_param = period_begin THEN return 2; END IF; IF until_date_param=period_end THEN return 3; END IF; END IF; RETURN 4; ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Beta Testing of postgresql-8.0.0-beta5
Siva, thank you very much for all your reporting! I would like to ask you for one more favour: within the installer there is bundled quite a lot of different products, esp. postgreSQL, pg_admin, ODBC/ JDBD / .NET installers, Contrib-Modules and finally the installer All these products are created, supported and maintained by volunteers for free; and especially by different volunteers. So I kindly ask you to "spread" your reports to the appropriate people: probs concerning the installer like: 1. When the user installs postgresql-8.0.0-beta5 and in the process he puts > "entire feature will be unavailable" in PostgreSQL in stallation options > window, the installer still proceeds could be put within the pgfoundry bug tracker. Bugs concerning pgadmin should be directed to the mailto:[EMAIL PROTECTED] pgadmin-mailinglist; also available from the www.pgadmin.org website. and finally bugs concerning the core postgres (or all you cannot direct :) may be sent to the pgsql-bugs mailinglist. Best wishes, Harald -- GHUM Harald Massa Harald Armin Massa Reinsburgstraße 202b 70197 Stuttgart 0173/9409607 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #1330: Incorrect String Order By In tr_TR Locale
The following bug has been logged online:
Bug reference: 1330
Logged by: Özgür Çaycı
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0 Beta
Operating system: Debian Woody
Description:Incorrect String Order By In tr_TR Locale
Details:
I use 8.0 Beta-5.
I am using a PostgreSQL cluster which I have created with locale tr_TR. When
I use "Order By", the strings are not ordered correctly. The spaces are
ignored when I use "Order By" clause. Here is a sample SQL dump to re-create
this situation:
CREATE TABLE mytable (
mytext character varying(255)
);
INSERT INTO mytable VALUES ('Güngör, Ahmet');
INSERT INTO mytable VALUES ('Güngör, Bengi');
INSERT INTO mytable VALUES ('Güngördü, Ersin');
INSERT INTO mytable VALUES ('Güngören, Bora');
INSERT INTO mytable VALUES ('Güngör, Erhan');
INSERT INTO mytable VALUES ('Güngör, Erol');
When I try 'Select * FROM mytable ORDER BY mytext ASC'
I get the following output:
Güngör, Ahmet
Güngör, Bengi
Güngördü, Ersin
Güngören, Bora
Güngör, Erhan
Güngör, Erol
The expected result is as follows:
Güngör, Ahmet
Güngör, Bengi
Güngör, Erhan
Güngör, Erol
Güngördü, Ersin
Güngören, Bora
Özgür
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [BUGS] BUG #1330: Incorrect String Order By In tr_TR Locale
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Fri, 26 Nov 2004, PostgreSQL Bugs List wrote: I use 8.0 Beta-5. I am using a PostgreSQL cluster which I have created with locale tr_TR. When I use "Order By", the strings are not ordered correctly. The spaces are ignored when I use "Order By" clause. Here is a sample SQL dump to re-create this situation: When I try 'Select * FROM mytable ORDER BY mytext ASC' I get the following output: Güngör, Ahmet Güngör, Bengi Güngördü, Ersin Güngören, Bora Güngör, Erhan Güngör, Erol The expected result is as follows: Güngör, Ahmet Güngör, Bengi Güngör, Erhan Güngör, Erol Güngördü, Ersin Güngören, Bora Upgrade to latest glibc. Debian unstable does not have this problem. http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/localedata/locales/tr_TR?cvsroot=glibc See http://yunus.listweb.bilkent.edu.tr/Linux/linux-programlama/2004/May/0061.html and all mails in the thread for more information. Regards, - -- Devrim GUNDUZ devrim~gunduz.orgdevrim.gunduz~linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBp1qStl86P3SPfQ4RAncwAJ9hXpZjz7FF3I/LgEKrVFqhvbbtVgCgtvsl 89QTPJs/hMk2jY292mGY8Iw= =kPSL -END PGP SIGNATURE- ---(end of broadcast)--- TIP 8: explain analyze is your friend
[BUGS] Version control for DLLs installed into WINNT/system32
I've found that if you have installed a previous beta release (e.g. beta4) and deinstall it, then the DLLs in system32 are not removed (e.g. libpq.dll). Furthermore, if you then install beta5, it does not complain but doesn't overwrite the old versions either. As a consequence, the old DLLs are used by beta5 and the DB does not work. The same applies to libeay32.dll. _ Ein sicherer Chat, eine nette Konversation oder eine produktive Zusammenarbeit! http://messenger.msn.at?DI=1031&XAPID=2532 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] Build libpq for win32
Hi! I need libpq static library for my Borland compiler (win32). make -DCFG=Release /f bcc32.makis not working in 8.0.0beta5 sourcesand is working nicely in 7.4.6 sources... Vlad Ovcharenko, Russia
[BUGS] postgresql-8.0.0-beta5-en.msi -- does not install
Dear POSTGRESQL developers, I would like to test the new PostgreSQL version, but was not able to start postgresql-8.0.0-beta5-en.zip i.e., the Windows Installer stopped without saying anything. That happen under Windows 2000 _and_ under Windows XP. The same happened with older Beta-Versions, I had to go back to postgresql-8.0-beta2-dev2.zip to download a version that installed. But I do not want to test older versions -- can you help me? Regards, Hans Werner Borchers. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] Version control for DLLs installed into WINNT/system32
> I've found that if you have installed a previous beta release > (e.g. beta4) and deinstall it, then the DLLs in system32 are > not removed (e.g. libpq.dll). That is not good, and needs to be fixed. Please log a bug with the pginstaller project on pgfoundry.org. > Furthermore, if you then install beta5, it does > not complain but doesn't overwrite the old versions either. That is normal. We don't bump file versions during beta. Once a new production release is installed it will have a higher version number on libpq.dll, and the file will automatically be replaced. > As a consequence, the old DLLs are used by beta5 and the DB > does not work. > The same applies to libeay32.dll. The uninstall part. This file has not changed during beta, though, so it shouldn't be a problem. A problem with this file is that we pull it in from upstream, and it doesn't have a versioninfo tag... //Magnus ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] postgresql-8.0.0-beta5-en.msi -- does not install
> Dear POSTGRESQL developers, > > I would like to test the new PostgreSQL version, but was not > able to start > > postgresql-8.0.0-beta5-en.zip > > i.e., the Windows Installer stopped without saying anything. > That happen under Windows 2000 _and_ under Windows XP. The > same happened with older Beta-Versions, I had to go back to > > postgresql-8.0-beta2-dev2.zip > > to download a version that installed. But I do not want to > test older versions -- can you help me? Please check your eventlog and see if it says anything when you try the install. If it doesn't, try enabling logging from Windows Installer by running: msiexec /l*v logfile.txt /i postgresql-8.0.0-beta5-en.msi and then check the contents of logfile.txt. //Magnus ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] BUG #1329: Bug in IF-ELSEIF-ELSE construct
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > Description:Bug in IF-ELSEIF-ELSE construct There is no ELSEIF construct. Try ELSIF. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] use of initcap() causes segfault in v8.0.0beta5, where it doesn't in v7.4.6 (coredump included)
L.S.
I've been using a certain pgsql function (IMMUTABLE/STRICT) happily in v7.4.6,
but when trying out v8.0.0beta5 the exact same function causes the backend to
segfault.
(Further examination revealed that a simple 'select initcap('f')' is enough to
bring the backend down..)
db=# select version();
version
--
PostgreSQL 8.0.0beta5 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66
Since this probably has to do with the db encoding, both versions of pgsql
were initdb'd using UNICODE and no-locale.
# uname -a
Linux gatefox 2.2.16 #15 Wed Feb 12 12:14:42 CET 2003 i686 unknown
(yes, fairly old, I know)
db=# update article set full_descr = full_article_descr(id);
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.
OR
db=# select initcap('f');
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.
LOG: server process (PID 31890) was terminated by signal 11
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing
LOG: database system was interrupted at 2004-11-26 23:48:26 CET
LOG: checkpoint record is at 0/2F7C3C50
LOG: redo record is at 0/2F7C3C50; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID: 37413; next OID: 1929207
LOG: database system was not properly shut down; automatic recovery in
progress
LOG: record with zero length at 0/2F7C3C8C
LOG: redo is not required
LOG: database system is ready
(gdb) where
#0 0x4016e501 in towupper () from /lib/libc.so.6
#1 0x81a45e2 in initcap (fcinfo=0xbfffdfdc) at oracle_compat.c:312
#2 0x8110ca1 in ExecMakeFunctionResult (fcache=0x8374fe0, econtext=0x837420c,
isNull=0xbfffe1c5 "", isDone=0xbfffe0e4) at execQual.c:1038
#3 0x8111401 in ExecEvalFunc (fcache=0x8374fe0, econtext=0x837420c,
isNull=0xbfffe1c5 "", isDone=0xbfffe0e4) at execQual.c:1455
#4 0x81108cc in ExecEvalFuncArgs (fcinfo=0xbfffe134, argList=0x8374fc4,
econtext=0x837420c) at execQual.c:795
#5 0x81109c1 in ExecMakeFunctionResult (fcache=0x8374e6c, econtext=0x837420c,
isNull=0xbfffe31c "", isDone=0xbfffe23c) at execQual.c:856
#6 0x811143d in ExecEvalOper (fcache=0x8374e6c, econtext=0x837420c,
isNull=0xbfffe31c "", isDone=0xbfffe23c) at execQual.c:1477
#7 0x81108cc in ExecEvalFuncArgs (fcinfo=0xbfffe28c, argList=0x837529c,
econtext=0x837420c) at execQual.c:795
#8 0x81109c1 in ExecMakeFunctionResult (fcache=0x8374d60, econtext=0x837420c,
isNull=0xbfffe474 "", isDone=0xbfffe394) at execQual.c:856
#9 0x811143d in ExecEvalOper (fcache=0x8374d60, econtext=0x837420c,
isNull=0xbfffe474 "", isDone=0xbfffe394) at execQual.c:1477
#10 0x81108cc in ExecEvalFuncArgs (fcinfo=0xbfffe3e4, argList=0x8375574,
econtext=0x837420c) at execQual.c:795
#11 0x81109c1 in ExecMakeFunctionResult (fcache=0x8374c54, econtext=0x837420c,
isNull=0xbfffe577 "", isDone=0x0) at execQual.c:856
#12 0x811143d in ExecEvalOper (fcache=0x8374c54, econtext=0x837420c,
isNull=0xbfffe577 "", isDone=0x0) at execQual.c:1477
#13 0x8112bad in ExecEvalExprSwitchContext (expression=0x8374c54,
econtext=0x837420c, isNull=0xbfffe577 "", isDone=0x0) at execQual.c:2708
#14 0x4148247b in exec_eval_simple_expr (estate=0xbfffe700, expr=0x833c9f0,
isNull=0xbfffe577 "", rettype=0xbfffe578) at pl_exec.c:3635
#15 0x41481f5d in exec_eval_expr (estate=0xbfffe700, expr=0x833c9f0,
isNull=0xbfffe577 "", rettype=0xbfffe578) at pl_exec.c:3418
#16 0x414811a1 in exec_assign_expr (estate=0xbfffe700, target=0x836a954,
expr=0x833c9f0) at pl_exec.c:2801
#17 0x4147ef7e in exec_stmt_assign (estate=0xbfffe700, stmt=0x833ca78) at
pl_exec.c:1143
#18 0x4147ed7e in exec_stmt (estate=0xbfffe700, stmt=0x833ca78) at
pl_exec.c:1047
#19 0x4147ec9f in exec_stmts (estate=0xbfffe700, stmts=0x8352080) at
pl_exec.c:1015
#20 0x4147ebdf in exec_stmt_block (estate=0xbfffe700, block=0x836d828) at
pl_exec.c:970
#21 0x4147df03 in plpgsql_exec_function (func=0x832c980, fcinfo=0xbfffe7b8) at
pl_exec.c:336
#22 0x4147af9b in plpgsql_call_handler (fcinfo=0xbfffe7b8) at pl_handler.c:127
#23 0x8110ca1 in ExecMakeFunctionResult (fcache=0x8356ffc, econtext=0x8356de0,
isNull=0xbfffe9a0 "", isDone=0xbfffe8c0) at execQual.c:1038
#24 0x8111401 in ExecEvalFunc (fcache=0x8356ffc, econtext=0x8356de0,
isNull=0xbfffe9a0 "", isDone=0xbfffe8c0) at execQual.c:1455
#25 0x81108cc in ExecEvalFuncArgs (fcinfo=0xbfffe910, argList=0x8357140,
econtext=0x8356de0) at execQual.c:795
#26 0x81109c1 in ExecMakeFunctionResult (fcache=0x8356ef0, econtext=0x8356de0,
isNull=0xbfffea27 "", isDone=0x83598e0) at execQual.c:856
#27 0x8111401 in ExecEvalFunc (fcache=0x8356ef0, econtext=0x8356de0,
Re: [BUGS] use of initcap() causes segfault in v8.0.0beta5, where it doesn't in v7.4.6 (coredump included)
Frank van Vugt <[EMAIL PROTECTED]> writes:
> (Further examination revealed that a simple 'select initcap('f')' is
> enough to bring the backend down..)
Works for me in unicode encoding + C locale on a couple different platforms.
> # uname -a
> Linux gatefox 2.2.16 #15 Wed Feb 12 12:14:42 CET 2003 i686 unknown
> (yes, fairly old, I know)
Possibly a bug in your old glibc version?
Can anyone else reproduce this?
> (gdb) where
> #0 0x4016e501 in towupper () from /lib/libc.so.6
> #1 0x81a45e2 in initcap (fcinfo=0xbfffdfdc) at oracle_compat.c:312
Since towupper takes an integer not a pointer, it's hard to see why a
crash within it wouldn't be a bug in towupper rather than being blamable
on bad supplied data.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] use of initcap() causes segfault in v8.0.0beta5, where it doesn't in v7.4.6 (coredump included)
> Since this probably has to do with the db encoding, both versions of pgsql > were initdb'd using UNICODE and no-locale. BTW, would you confirm that that means u=# show server_encoding; server_encoding - UNICODE (1 row) u=# show lc_ctype; lc_ctype -- C (1 row) u=# regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] use of initcap() causes segfault in v8.0.0beta5, where it doesn't in v7.4.6 (coredump included)
> Possibly a bug in your old glibc version? Could be, a quick search does reveal some reports on a problem with the combination of glibc 2.1.3 an towupper. I'll look into the possibility of upgrading libc, but given the source of oracle_compat.c, would it be possible to get the v7.4.6 behaviour back for the time being by fiddling the #define USE_WIDE_UPPER_LOWER ? Or maybe by using some specific configure option? > BTW, would you confirm that that means It does: db=# show server_encoding; server_encoding - UNICODE (1 row) db=# show lc_ctype; lc_ctype -- C (1 row) Hopefully some other Slackware / Debian user can confirm the segfault? -- Best, Frank. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] use of initcap() causes segfault in v8.0.0beta5, where it doesn't in v7.4.6 (coredump included)
Frank van Vugt <[EMAIL PROTECTED]> writes: > I'll look into the possibility of upgrading libc, but given the source of > oracle_compat.c, would it be possible to get the v7.4.6 behaviour back for > the time being by fiddling the #define USE_WIDE_UPPER_LOWER ? Yeah, IIRC it should be a one-liner kind of change to force the non-towupper fallback. If this turns out to be a widespread bug we might have to consider making configure know about it :-( regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Sequence creation bug: 8.0.0beta4 win32
I could not reproduce any of your problems on Win32 or Unix. Are you
still seeing these failures?
---
Nick Farrell wrote:
> Hi. I'm seeing a couple of strange things.
>
> default encoding: unicode
> locale: en_AU
> running psql from localhost, I appear able to create a sequence, but I
> get an error whenever I try to use it. This code runs fine on linux
> (though the linux DB is v7.5.X).
>
> In addition, the log snippet below shows more strangeness when I try
> to create a new database. This is strange as the 'call' database was
> itself created while running the attached script (starting in
> template1). If it's important, the below code was run after the
> attached code was run (with errors relating to the sequence)
>
> call=# create sequence testseq;
> CREATE SEQUENCE
> call=# create table testtab1 (id integer default 1);
> CREATE TABLE
> call=# create table testtab2 (id integer default nextval('testseq'));
> ERROR: could not open relation 1663/17270/16719: No such file or directory
> call=# create database testdb
> call-# ;
> CREATE DATABASE
> call=# \c testdb
> could not receive server response to SSL negotiation packet: Software caused
> con
> nection abort (0x2745/10053)
> Previous connection kept
> call=# \c testdb
> could not receive server response to SSL negotiation packet: Software caused
> con
> nection abort (0x2745/10053)
> Previous connection kept
[ Attachment, skipping... ]
>
> ---(end of broadcast)---
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [BUGS] BUG #1329: Bug in IF-ELSEIF-ELSE construct
Tom Lane wrote: There is no ELSEIF construct. Sure, but it would be nice to throw a syntax error rather than silently accepting the function. Unfortunately the way PL/PgSQL's parser works doesn't make this very easy. (BTW, I think that fixing how we do parsing would be one of the prime motivations for rewriting PL/PgSQL. One possibility would be to integrate the PL/PgSQL parser into the main SQL parser, although there may be a cleaner way to improve PL/PgSQL parsing.) In any case, given this function: create or replace function foo() returns int as ' #option dump begin if 5 > 5 then return 10; elseif 5 > 6 then return 15; else return 20; end if; end;' language 'plpgsql'; We produce this parsetree: (helpfully dumped via the undocumented "#option dump" feature) Functions statements: 2:BLOCK <<*unnamed*>> 3: IF 'SELECT 5 > 5' THEN 4:RETURN 'SELECT 10' 5:EXECSQL 'elseif 5 > 6 then 15 15' ELSE 8:RETURN 'SELECT 20' ENDIF END -- *unnamed* One way to fix the specific bug reported here would be to add K_ELSEIF to the PL/PgSQL lexer, and then throw a syntax error in the stmt_else production. But that is a very limited fix: if the user specifies any other word in the place of 'elseif', we will not throw a syntax error. Another solution would be to teach the PL/PgSQL lexer to recognize the initial tokens of every SQL statement (SELECT, UPDATE, and so forth). Right now we just assume an unrecognized word must be the beginning of a SQL statement; if we taught the lexer about the initial tokens of all legal SQL statements, we could reject unrecognized words. But this is kind of ugly as well, as it means duplicating the knowledge about what constitutes a legal SQL statement in multiple places. Alternatively, we could arrange to have the PL/PgSQL parser pass a block of text it has identified as a possible SQL statement to the main SQL parser; if it produces a syntax error, we can pass that syntax error back to the user. I'm not sure if this would have any negative ramifications, though. Comments? (BTW, another thing this example exposes is that we don't issue warnings about trivially-dead-code, such as statements in a basic block that follow a RETURN. This would probably be also worth doing.) -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
