[BUGS] 7.3.3 ADD COLUMN wierdness
I'm running two different strains of PostgreSQL 7.1.3, which is what our website is running off of now and 7.3.3, which we hope to move to (sometime). In 7.1.3 I can say ALTER TABLE blah ADD COLUMN whatever integer not null; and as expected, that works fine on 7.3.3 the same command returns Adding NOT NULL columns is not implemented. Add the column, then use ALTER TABLE ... SET NOT NULL. Hmm, the last time I checked, this should have worked. Is this a bug or a feature? If it's a feature, can I turn it off, because this is a hassel. This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] 7.3.3 ADD COLUMN wierdness
On Mon, 2003-06-16 at 07:53, Brian O'Donoghue wrote: > I'm running two different strains of PostgreSQL > > 7.1.3, which is what our website is running off of now and 7.3.3, which we > hope to move to (sometime). > > In 7.1.3 I can say > > ALTER TABLE blah ADD COLUMN whatever integer not null; CREATE TABLE bob(col integer); INSERT INTO bob VALUES (1); ALTER TABLE bob ADD COLUMN col2 integer NOT NULL; Now of course, the table has a NULL value for col2 which is not allowed per the NOT NULL constraint. Until we allow processing of a DEFAULT expression during column creation, this will not work that way. You could argue we should allow NOT NULL to be added to an empty table. -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [BUGS] 7.3.3 ADD COLUMN wierdness
Ah yes. ALTER TABLE blah ADD COLUMN whatever integer; UPDATE blah set whatever=1; ALTER TABLE blah ALTER COLUMN whatever SET NOT NULL; Produces the desired effect. I was thinking something along the lines of ALTER TABLE blah ADD COLUMN whatever integer not null default 1; should work, but the above is just as handy. This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] 7.3.3 ADD COLUMN wierdness
"Brian O'Donoghue" <[EMAIL PROTECTED]> writes: > ALTER TABLE blah ADD COLUMN whatever integer not null; > Adding NOT NULL columns is not implemented. > Add the column, then use ALTER TABLE ... SET NOT NULL. > Hmm, the last time I checked, this should have worked. Although 7.1 allowed that, it did not work correctly --- the NOT NULL wasn't checked. 7.3 is aware that it can't handle it :-). You can do ALTER TABLE ADD COLUMN, then UPDATE to fill all the rows with a suitable value, then ALTER again to set the NOT NULL constraint. Yeah, it's a pain, but no one's gotten around to writing the code that would be needed to handle doing this in one step. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] 7.3.3 ADD COLUMN wierdness
"Brian O'Donoghue" <[EMAIL PROTECTED]> writes: > I was thinking something along the lines of > ALTER TABLE blah ADD COLUMN whatever integer not null default 1; > should work, It should, we just haven't got round to implementing that combination yet. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] commands
i want how to start the postsql in redhat linux 8 & how to access the data base postgresql in linux i have ms access 2000 db its possible to access in linux go throw in postgresql ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] fe-connect build failure (Solaris 9, PGSQL 7.3.3, OpenSSL 0.9.7b)
I ran into the following problem building PostgreSQL 7.3.3 on Solaris
9 (sparc) using GCC 3.3 and OpenSSL 0.9.7b.
gcc -g -Wall -Wmissing-prototypes -Wmissing-declarations -fPIC -I.
-I../../../src/include -I/opt/reb/include -I/opt/sfw/include -DFRONTEND
-DSYSCONFDIR='"/opt/reb/etc/postgresql"' -c -o fe-connect.o fe-connect.c
In file included from fe-connect.c:46:
/usr/include/crypt.h:22: error: parse error before '(' token
/usr/include/crypt.h:22: error: parse error before "const"
gmake[4]: *** [fe-connect.o] Error 1
gmake[4]: Leaving directory
`/net/cog/project/reb/src/base/postgresql/src/interfaces/libpq'
This is the OpenSSH-versus-crypt.h compatibility issue that is discussed
in doc/FAQ_Solaris thusly:
2) Why do I get problems when building with OpenSSL support?
When you build PostgreSQL with OpenSSL support you might get
compilation errors in the following files:
src/backend/libpq/crypt.c
src/backend/libpq/password.c
src/interfaces/libpq/fe-auth.c
src/interfaces/libpq/fe-connect.c
This is because of a namespace conflict between the standard
/usr/include/crypt.h header and the header files provided by OpenSSL.
Upgrading your OpenSSL installation to version 0.9.6a fixes this
problem.
Apparently the problem has come back (in limited form) in OpenSSL 0.9.7b,
the current version of OpenSSL.
I worked around the problem as follows. However, I don't offhand see
why fe-connect.c has to include at all, so perhaps a simpler
fix is to remove the #include on all platforms.
===
RCS file: src/interfaces/libpq/fe-connect.c,v
retrieving revision 7.3.3.0
retrieving revision 7.3.3.1
diff -pu -r7.3.3.0 -r7.3.3.1
--- src/interfaces/libpq/fe-connect.c 2003/01/30 19:50:07 7.3.3.0
+++ src/interfaces/libpq/fe-connect.c 2003/06/12 21:06:06 7.3.3.1
@@ -42,7 +42,7 @@
#ifndef HAVE_STRDUP
#include "strdup.h"
#endif
-#ifdef HAVE_CRYPT_H
+#if defined(HAVE_CRYPT_H) && !defined(des_crypt)
#include
#endif
---(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
[BUGS] Bug: ipcclean didn't work on HP-PA platform
Hello Sir, I executed the PostgreSQL binary ipcclean on HP-PA 11.11 platform.When I executed the ipcclean binary, it gives the following error: $ su postgres $ ipccleanYou cannot run ipcclean as root. Please log in (using, e.g., 'su')as the (unprivileged) user that owned the server process.$ Eventhough I executed the ipcclean as "postgres " user. But I didn't get result. Expecting your mail for confirmation whether my testing is wrong or correct. Regards, Durai.
[BUGS] Missing Make Files
Don't know if this indicates a bug or an incomplete download, but: Downloaded postgresql-7.3.3.tar.gz and unpacked it on our system (sparc-sun-solaris2.6); ran the configure script, apparently successfully (non-fatal warnings about not finding flex, bison, and zlib), and then attempted to do make, with repeated error messages like this: You need to run the 'configure' program first. See the file 'INSTALL' for installation instructions. make: *** [all] Error 255 Inspected the configure and make scripts, and discovered references to GNUmakefile and src/Makefile.global; but the postgresql-7.3.3 directories do not have these files; there is a GNUmakefile.in and a src/Makefile.global.in, but no plain GNUmakefile or Makefile.global; are these files supposed to be created during configure? If so, what might have gone wrong during the configure (config.log attached)? If not, where can we acquire these files? -- David Rickard Software Engineer The GTS Companies A TechBooks Company -- The GTS Companies: GTS Publishing Services, GTS Graphics, GTS Innova: Your Single-Source Solution! Los Angeles CA * York, PA * Boston MA * New Delhi, India -- [EMAIL PROTECTED] Visit us on the World Wide Web http://www.gtscompanies.com 5650 Jillson St., Los Angeles, CA 90040 (323) 888-8889 x331 (323) 888-1849 [fax] config.log Description: Binary data ---(end of broadcast)--- TIP 8: explain analyze is your friend
[BUGS] bug in pg.py and the fix
If PostgreSQL failed to compile on your computer or you found a bug that is likely to be specific to one platform then please fill out this form and e-mail it to [EMAIL PROTECTED] To report any other bug, fill out the form below and e-mail it to [EMAIL PROTECTED] If you not only found the problem but solved it and generated a patch then e-mail it to [EMAIL PROTECTED] instead. Please use the command "diff -c" to generate the patch. You may also enter a bug report at http://www.postgresql.org/ instead of e-mail-ing this form. POSTGRESQL BUG REPORT TEMPLATE Your name : Chih-Hao Huang Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Intel Pentium Operating System (example: Linux 2.0.26 ELF) : Linux 2.4.3-12 PostgreSQL version (example: PostgreSQL-7.3.3): PostgreSQL-7.3.3 Compiler used (example: gcc 2.95.2) : gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-85) Please enter a FULL description of your problem: This is a bug in python interface module, postgresql-7.3.3/src/interfaces/python/pg.py. _quote() function fails due to integer overflow if input d is larger than max integer. In the case where the column type is "BIGINT", the input d may very well be larger than max integer while its type, t, is labeled 'int'. The conversion on line 19, return "%d" % int(d), will fail due to "OverflowError: long int too large to convert to int". Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- [1] create a table with a column type 'BIGINT'. [2] use pg.DB.insert() to insert a value that is larger than max integer If you know how this problem might be fixed, list the solution below: - Just changing the conversion at line 19 of pg.py to long(d) instead of int(d) should fix it. The following is a patch: *** pg.py Fri Jun 13 15:15:57 2003 --- pg.py.new Fri Jun 13 15:16:59 2003 *** *** 16,22 if t in ['int', 'seq']: if d == "": return "NULL" ! return "%d" % int(d) if t == 'decimal': if d == "": return "NULL" --- 16,22 if t in ['int', 'seq']: if d == "": return "NULL" ! return "%d" % long(d) if t == 'decimal': if d == "": return "NULL" ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] bug in pg.py and the fix
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Chih-Hao Huang wrote: > If PostgreSQL failed to compile on your computer or you found a bug that > is likely to be specific to one platform then please fill out this form > and e-mail it to [EMAIL PROTECTED] > > To report any other bug, fill out the form below and e-mail it to > [EMAIL PROTECTED] > > If you not only found the problem but solved it and generated a patch > then e-mail it to [EMAIL PROTECTED] instead. Please use the > command "diff -c" to generate the patch. > > You may also enter a bug report at http://www.postgresql.org/ instead of > e-mail-ing this form. > > > POSTGRESQL BUG REPORT TEMPLATE > > > > Your name : Chih-Hao Huang > Your email address: [EMAIL PROTECTED] > > > System Configuration > - > Architecture (example: Intel Pentium) : Intel Pentium > > Operating System (example: Linux 2.0.26 ELF): Linux 2.4.3-12 > > PostgreSQL version (example: PostgreSQL-7.3.3): PostgreSQL-7.3.3 > > Compiler used (example: gcc 2.95.2): gcc version 2.96 2731 > (Red Hat Linux 7.1 2.96-85) > > > Please enter a FULL description of your problem: > > > This is a bug in python interface module, > postgresql-7.3.3/src/interfaces/python/pg.py. > > _quote() function fails due to integer overflow if input d is larger > than max integer. > > In the case where the column type is "BIGINT", the input d may very well > be larger than max integer while its type, t, is labeled 'int'. > The conversion on line 19, return "%d" % int(d), will fail due to > "OverflowError: long int too large to convert to int". > > > > Please describe a way to repeat the problem. Please try to provide a > concise reproducible example, if at all possible: > -- > > [1] create a table with a column type 'BIGINT'. > [2] use pg.DB.insert() to insert a value that is larger than max integer > > If you know how this problem might be fixed, list the solution below: > - > > Just changing the conversion at line 19 of pg.py to long(d) instead of > int(d) should fix it. The following is a patch: > > *** pg.py Fri Jun 13 15:15:57 2003 > --- pg.py.new Fri Jun 13 15:16:59 2003 > *** > *** 16,22 > > if t in ['int', 'seq']: > if d == "": return "NULL" > ! return "%d" % int(d) > > if t == 'decimal': > if d == "": return "NULL" > --- 16,22 > > if t in ['int', 'seq']: > if d == "": return "NULL" > ! return "%d" % long(d) > > if t == 'decimal': > if d == "": return "NULL" > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faqs/FAQ.html > -- 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 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] Missing Make Files
David Rickard <[EMAIL PROTECTED]> writes: > Downloaded postgresql-7.3.3.tar.gz and unpacked it on our system > (sparc-sun-solaris2.6); ran the configure script, apparently successfully > (non-fatal warnings about not finding flex, bison, and zlib), The zlib error was fatal: configure:5964: error: zlib library not found If you have zlib already installed, see config.log for details on the failure. It is possible the compiler isn't looking in the proper directory. Use --without-zlib to disable zlib support. regards, tom lane ---(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
