Re: [HACKERS] Announcing PgSQL - a Python DB-API 2.0 compliantinterface to PostgreSQL
Nope, neigher PyGreSQL nor ""PGSQL"" are products of Pgsql.com (aka PostgreSQL Inc)On Mon, 9 Oct 2000, Vince Vielhaber wrote: On Mon, 9 Oct 2000, Bruce Momjian wrote: I need to know how this is different than our current python interface, PyGreSQL. Is this a product of pgsql.com? Vince. Jeff MacDonald, - PostgreSQL Inc | Hub.Org Networking Services [EMAIL PROTECTED] | [EMAIL PROTECTED] www.pgsql.com | www.hub.org 1-902-542-0713 | 1-902-542-3657 - Facsimile : 1 902 542 5386 IRC Nick : bignose
Re: [HACKERS] ALTER TABLE DROP COLUMN
The Hermit Hacker wrote: On Mon, 9 Oct 2000, Bruce Momjian wrote: Ya, but in one email, you appear to agree with me ... then Tom posts a good point and you jump over to that side ... at least pick a side? :) I too wish to see it implemented, I just don't want to have to double my disk space if at some point I decide to upgrade an application and find out that they decided to change their schema(s) :( As Don already pointed out, if you don't have enough room to double your table size you must be running an one-table, append-only application where you can only do a very limited set of queries. select * from that_table order by some_column_without_an_index; is definitely out as it takes many times the space of a that_table anyway. There _may_ be some cases where 2x is unacceptable, but without radically changing tables on-disk structure there is no way to avoid it and still be able to rollback or even crash cleanly ;) - Hannu
Re: [HACKERS] CVS broken?
-Wmissing-prototypes -Wmissing-declarations -o pg_dump pg_dump.o common.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o -L../../.. /src/interfaces/libpq -lpq -lz -lcrypt -lnsl -ldl -lm -lreadline -lncurses -lz ../../../src/interfaces/libpq/libpq.so: undefined reference to `FailedAssertion' ../../../src/interfaces/libpq/libpq.so: undefined reference to `assert_enabled' ../../../src/interfaces/libpq/libpq.so: undefined reference to `ExceptionalCondition' Does anyone else have this problem? I have already encountered the problem. -DFRONTEND isn't set in the above command line. For example the following line CFLAGS+= -DFRONTEND -I$(srcdir) in makefiles doesn't work currently. I found the recent change in Makefile.global.in. ifeq ($(GCC), yes) override CFLAGS += -Wall -Wmissing-prototypes -Wmissing-declarations endif OK, I have removed 'override' from CFLAGS, and committed. Seems like it came in with: date: 2000/10/08 21:13:27; author: petere; state: Exp; lines: +165 -137 Append "/postgresql" to (certain) installation subdirectories when installing into a shared location. Also Makefile.global organizational cleanup. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Suggested change in include/utils/elog.h
On Sun, Oct 08, 2000 at 01:37:45PM -0400, Bruce Momjian wrote: But perhaps it is ecpg's fault for including "elog.h". IMHO these defines should never leave the database kernel. ... Yes, leaking into user programs is a bad practice. Is there a solution/patch for that? Hmm, I haven't check carefully, but I don't think ecpg include elog.h directly. Maybe I just picked the wrong file to include. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
[HACKERS] Re: [PATCHES] Re: [ANNOUNCE] Announce: Release of PyGreSQL version3.0
The Hermit Hacker writes: Announce: Release of PyGreSQL version 3.0 When is 7.1 being locked down? I may be releasing 3.1 with a few small fixes and changes very soon. you should be safe until mid-december or so ... as PyGreSQL doesn't affect the build of PostgreSQL in anyway that I'm aware of, there is no reason why you should be constrained to our beta cycle ... If you configure --with-python, then it will, so it would be advantageous to get it in with/before beta. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [INTERFACES] Re: [HACKERS] Announcing PgSQL - a Python DB-API2.0 compliant interface to PostgreSQL
Bruce Momjian writes: I need to know how this is different than our current python interface, PyGreSQL. PgSQL is a package of two (2) modules that provide a Python DB-API 2.0 compliant interface to PostgreSQL databases. DB-API is the standard database interface for Python. Kind of like DBD/DBI for Perl. The existing one is hand-crafted, kind of like the Pg Perl module. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] CVS broken?
Hiroshi Inoue writes: For example the following line CFLAGS+= -DFRONTEND -I$(srcdir) in makefiles doesn't work currently. I found the recent change in Makefile.global.in. ifeq ($(GCC), yes) override CFLAGS += -Wall -Wmissing-prototypes -Wmissing-declarations endif Seems like a problem in make. What versions are you using? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [GENERAL] Re: [HACKERS] My new job
Bruce Momjian wrote: As promised, the press release is at: http://www.greatbridge.com/news/p_101020001.html Wow. Nice. The combined qualifications of the six steering committee members are staggering. Me, I'm just a lowly broadcast engineer with ten years experience and a measly Bachelor's degree in Electronics Engineering Technology. Oh well. Even I have a job to do! -- Lamar Owen WGCR Intermet Radio 1 Peter 4:11
Re: [HACKERS] Modified pg_dump new pg_restore need testing...
Philip, where did we leave this? If anyone is interested in being sent the current sources for the new pg_dump pg_restore, please let me know. The utilities now seem to work, but need testing. The basic idea is to use pg_dump to dump an *entire* database, and then use pg_restore to choose what is restored. The salient features are as follows: - pg_dump still used to dump database; all output is via new interface (virtually all of the pg_dump code is changed, but not the logic). The changes are relatively minor, all the same. - the '-c' option is not used in pg-dump: it now dumps the commands to delete the schema, and it is up to the user of pg_restore to decide if they are output. - the default output file format is a custom format with compressed sections (the data dumps). It is NOT a text file. - pg_restore reads the backup file and, depending on the options chosen, produces a script (to stdout) that can be sent to psql. - by default pg_restore outputs the schema/data in the order it was sent from pg_dump, but the --oid flag will send the output in order of increasing OID, and the --rearrange flag will put all 'non-parental' (??) items at the end, after the data. (eg. indexes, acls, triggers etc). Needless to say that the best results com from using both of these options. - If the -c (clear) option is chosen in pg_restore, it also dumps the 'drop' commands in reverse order at the start of the script. This *should* make it more reliable than dumping them when the item is defined. It also means that triggers can be dropped. - The --toc option shows a summary of the restore operation that would be performed if the --toc were not there. Please send me an email if you are interested and have the time to test them. Thanks, Philip Warner. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.C.N. 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] heap_create with OID? (fwd)
If anyone was following my request to have a large object api for TOAST, this is of interest. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 Tom Lane wrote: My own feeling is that the current LO setup is fundamentally flawed by its reliance on specific OID values, and that the right answer is to find a way to avoid that. contrib/lo might provide some food for thought here (although it's clearly not the whole answer either). I have some ideas to replace the entire LO handling by something completely different. More compatible with the Oracle way of handling large objects. That is, that on INSERT/UPDATE someone uses a function to place an LO reference into the tuple. Then having a new interface in libpq, that works like file I/O on the references that appear in a result set. To open them for writing, the user must have selected them for update, otherwise he can open them for reading. The file I/O itself can be based on the fastpath interface. The LO's follow Oracles copy semantic, so if someone does INSERT ... SELECT, the LO gets duplicated. All LO's for one base table can be stored in one big, segmented external heap (more or less like toast values). The system would automatically know when objects are obsolete. An INSERT operation might then return a result set as if someone did a SELECT FOR UPDATE of exactly what he just inserted. So he immediately has access to the LO references to place the values. Don't know yet how to interface it from psql - but let me sleep another night or so over it. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] #
Re: [HACKERS] Modified pg_dump new pg_restore need testing...
At 21:01 10/10/00 -0400, Bruce Momjian wrote: Philip, where did we leave this? In CVS. ;-). The longer answer is that it's been in CVS for a while, and I have a version for 7.0.2 which I have also been using for a while. Various people have tested it, but not as many or as much as I would like (or lots of people have tested it with no problems, which seems unlikely). The docs for pg_dump are with Thomas and I am about to start working on an unrelated bug in the way pg_dump handles sequences. When that's done, I will document pg_restore. Hopefully, all in time for beta... Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
[HACKERS] Re: [PATCHES] PostgreSQL virtual hosting support
I am tempted to apply this. This is the second person who asked for binding to a single port. The patch looks quite complete, with doc changes. It appears to be a thorough job. Any objections? Your name : David MacKenzie Your email address: [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Intel x86 Operating System (example: Linux 2.0.26 ELF): BSD/OS 4.0.1 PostgreSQL version (example: PostgreSQL-7.0): PostgreSQL-7.0.2 Compiler used (example: gcc 2.8.0) : gcc version 2.7.2.1 Please enter a FULL description of your problem: UUNET is looking into offering PostgreSQL as a part of a managed web hosting product, on both shared and dedicated machines. We currently offer Oracle and MySQL, and it would be a nice middle-ground. However, as shipped, PostgreSQL lacks the following features we need that MySQL has: 1. The ability to listen only on a particular IP address. Each hosting customer has their own IP address, on which all of their servers (http, ftp, real media, etc.) run. 2. The ability to place the Unix-domain socket in a mode 700 directory. This allows us to automatically create an empty database, with an empty DBA password, for new or upgrading customers without having to interactively set a DBA password and communicate it to (or from) the customer. This in turn cuts down our install and upgrade times. 3. The ability to connect to the Unix-domain socket from within a change-rooted environment. We run CGI programs chrooted to the user's home directory, which is another reason why we need to be able to specify where the Unix-domain socket is, instead of /tmp. 4. The ability to, if run as root, open a pid file in /var/run as root, and then setuid to the desired user. (mysqld -u can almost do this; I had to patch it, too). The patch below fixes problem 1-3. I plan to address #4, also, but haven't done so yet. These diffs are big enough that they should give the PG development team something to think about in the meantime :-) Also, I'm about to leave for 2 weeks' vacation, so I thought I'd get out what I have, which works (for the problems it tackles), now. With these changes, we can set up and run PostgreSQL with scripts the same way we can with apache or proftpd or mysql. In summary, this patch makes the following enhancements: 1. Adds an environment variable PGUNIXSOCKET, analogous to MYSQL_UNIX_PORT, and command line options -k --unix-socket to the relevant programs. 2. Adds a -h option to postmaster to set the hostname or IP address to listen on instead of the default INADDR_ANY. 3. Extends some library interfaces to support the above. 4. Fixes a few memory leaks in PQconnectdb(). The default behavior is unchanged from stock 7.0.2; if you don't use any of these new features, they don't change the operation. Index: doc/src/sgml/layout.sgml *** doc/src/sgml/layout.sgml 2000/06/30 21:15:36 1.1 --- doc/src/sgml/layout.sgml 2000/07/02 03:56:05 1.2 *** *** 55,61 For example, if the database server machine is a remote machine, you will need to set the envarPGHOST/envar environment variable to the name of the database server machine. The environment variable ! envarPGPORT/envar may also have to be set. The bottom line is this: if you try to start an application program and it complains that it cannot connect to the Applicationpostmaster/Application, you must go back and make sure that your --- 55,62 For example, if the database server machine is a remote machine, you will need to set the envarPGHOST/envar environment variable to the name of the database server machine. The environment variable ! envarPGPORT/envar or envarPGUNIXSOCKET/envar may also have to be set. ! The bottom line is this: if you try to start an application program and it complains that it cannot connect to the Applicationpostmaster/Application, you must go back and make sure that your Index: doc/src/sgml/libpq++.sgml *** doc/src/sgml/libpq++.sgml 2000/06/30 21:15:36 1.1 --- doc/src/sgml/libpq++.sgml 2000/07/02 03:56:05 1.2 *** *** 93,98 --- 93,105 /listitem listitem para + envarPGUNIXSOCKET/envar sets the full Unix domain socket + file name for communicating with the productnamePostgres/productname + backend. +/para + /listitem + listitem +para envarPGDATABASE/envar sets the default productnamePostgres/productname database name. /para Index: doc/src/sgml/libpq.sgml *** doc/src/sgml/libpq.sgml 2000/06/30 21:15:36 1.1 --- doc/src/sgml/libpq.sgml 2000/07/02 03:56:05 1.2 *** *** 134,139 --- 134,148
Re: [HACKERS] RE: [INTERFACES] Announcing PgSQL - a Python DB-API2.0 compliant interface to PostgreSQL
On Tue, 10 Oct 2000, The Hermit Hacker wrote: On Wed, 11 Oct 2000, Christopher Sawtell wrote: On Wed, 11 Oct 2000, [EMAIL PROTECTED] wrote: The project name on SourceForge is "Python Interface to PostgreSQL". How about PIPgSQL or piPgSQL? Perhaps Pi2PgSQL, or PySQL_ba PySQL_ba? *grin* Pyg ?? Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com ==
Re: [HACKERS] Re: [PATCHES] PostgreSQL virtual hosting support
Bruce Momjian wrote: I am tempted to apply this. This is the second person who asked for binding to a single port. The patch looks quite complete, with doc changes. It appears to be a thorough job. A cursory inspection makes it look like the socket file can be placed _anywhere_ -- even under a chroot jail. This would make more than one person's day, Bruce. This would allow a chrooted webserver to connect to a postmaster outside the jail -- while not terribly appealing from a security standpoint (as any pipe out of a jail could be exploited), it IS appealing when you need more than one chrooted webserver (doing virtual hosting) to connect ot a common database (for hosting-site-wide services). If this patch passes muster (muster pass Tom Lane's eyes), and you feel comfortable with it, I don't see why not -- this might not be a major feature, but it IS a nice one, IMHO. Now, if I'm wrong about the placement of the socket, well, I'm just wrong -- but the vhosting feature is still nice. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
[HACKERS] Re: [INTERFACES] Announcing PgSQL - a Python DB-API 2.0 compliant interface to PostgreSQL
Peter Eisentraut wrote: Billy G. Allie writes: PgSQL v1.0 has been released. This is the first public release of PgSQL. It is available at http://sourceforge.net/projects/pgsql. Sounds interesting, but isn't "pgsql" an extremely unfortunate choice of name, given that it's already used as an abbreviation for "PostgreSQL"? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ PgSQL is the name of the module you import in Python to access a PostgreSQL database from Python using the DB-API 2.0. The project name on SourceForge is "Python Interface to PostgreSQL". Of course, it there is too much heart burn with the modules name, I can change it. ___ | Billy G. Allie| Domain: [EMAIL PROTECTED] | /| | 7436 Hartwell | Compuserve: 76337,2061 |-/-|- | Dearborn, MI 48126| MSN...: [EMAIL PROTECTED] |/ |LLIE | (313) 582-1540|
Re: [HACKERS] Re: [PATCHES] PostgreSQL virtual hosting support
On Tue, 10 Oct 2000, Bruce Momjian wrote: I am tempted to apply this. This is the second person who asked for binding to a single port. The patch looks quite complete, with doc changes. It appears to be a thorough job. Any objections? From a quick read of his "description of problem", it sounds like he has addressed the original patches problem where it bound only to 127.0.0.1, and allows you to bind to any IP on that machine ... looks like a go for inclusion from what I can see ... Your name : David MacKenzie Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Intel x86 Operating System (example: Linux 2.0.26 ELF) : BSD/OS 4.0.1 PostgreSQL version (example: PostgreSQL-7.0): PostgreSQL-7.0.2 Compiler used (example: gcc 2.8.0) : gcc version 2.7.2.1 Please enter a FULL description of your problem: UUNET is looking into offering PostgreSQL as a part of a managed web hosting product, on both shared and dedicated machines. We currently offer Oracle and MySQL, and it would be a nice middle-ground. However, as shipped, PostgreSQL lacks the following features we need that MySQL has: 1. The ability to listen only on a particular IP address. Each hosting customer has their own IP address, on which all of their servers (http, ftp, real media, etc.) run. 2. The ability to place the Unix-domain socket in a mode 700 directory. This allows us to automatically create an empty database, with an empty DBA password, for new or upgrading customers without having to interactively set a DBA password and communicate it to (or from) the customer. This in turn cuts down our install and upgrade times. 3. The ability to connect to the Unix-domain socket from within a change-rooted environment. We run CGI programs chrooted to the user's home directory, which is another reason why we need to be able to specify where the Unix-domain socket is, instead of /tmp. 4. The ability to, if run as root, open a pid file in /var/run as root, and then setuid to the desired user. (mysqld -u can almost do this; I had to patch it, too). The patch below fixes problem 1-3. I plan to address #4, also, but haven't done so yet. These diffs are big enough that they should give the PG development team something to think about in the meantime :-) Also, I'm about to leave for 2 weeks' vacation, so I thought I'd get out what I have, which works (for the problems it tackles), now. With these changes, we can set up and run PostgreSQL with scripts the same way we can with apache or proftpd or mysql. In summary, this patch makes the following enhancements: 1. Adds an environment variable PGUNIXSOCKET, analogous to MYSQL_UNIX_PORT, and command line options -k --unix-socket to the relevant programs. 2. Adds a -h option to postmaster to set the hostname or IP address to listen on instead of the default INADDR_ANY. 3. Extends some library interfaces to support the above. 4. Fixes a few memory leaks in PQconnectdb(). The default behavior is unchanged from stock 7.0.2; if you don't use any of these new features, they don't change the operation. Index: doc/src/sgml/layout.sgml *** doc/src/sgml/layout.sgml2000/06/30 21:15:36 1.1 --- doc/src/sgml/layout.sgml2000/07/02 03:56:05 1.2 *** *** 55,61 For example, if the database server machine is a remote machine, you will need to set the envarPGHOST/envar environment variable to the name of the database server machine. The environment variable ! envarPGPORT/envar may also have to be set. The bottom line is this: if you try to start an application program and it complains that it cannot connect to the Applicationpostmaster/Application, you must go back and make sure that your --- 55,62 For example, if the database server machine is a remote machine, you will need to set the envarPGHOST/envar environment variable to the name of the database server machine. The environment variable ! envarPGPORT/envar or envarPGUNIXSOCKET/envar may also have to be set. ! The bottom line is this: if you try to start an application program and it complains that it cannot connect to the Applicationpostmaster/Application, you must go back and make sure that your Index: doc/src/sgml/libpq++.sgml *** doc/src/sgml/libpq++.sgml 2000/06/30 21:15:36 1.1 --- doc/src/sgml/libpq++.sgml 2000/07/02 03:56:05 1.2 *** *** 93,98 --- 93,105 /listitem listitem para + envarPGUNIXSOCKET/envar sets the full Unix domain socket + file name for communicating with the
[HACKERS] Re: [INTERFACES] Announcing PgSQL - a Python DB-API 2.0 compliant interface to PostgreSQL
Tom Lane wrote: "Billy G. Allie" [EMAIL PROTECTED] writes: Peter Eisentraut wrote: Sounds interesting, but isn't "pgsql" an extremely unfortunate choice of name, given that it's already used as an abbreviation for "PostgreSQL"? PgSQL is the name of the module you import in Python to access a PostgreSQL database from Python using the DB-API 2.0. The project name on SourceForge is "Python Interface to PostgreSQL". Of course, it there is too much heart burn with the modules name, I can change it. FWIW, my initial reaction was the same as Peter's: that name is certain to cause confusion. I don't want to try to force you to change it, but I think it's not a good choice. Don't have a better alternative to offer offhand, however. regards, tom lane I couldn't think of a better alternative, either. That's why the module name is PgSQL. Of course, seeing 'import PgSQL' in the python code seems to imply loading code to access PostgreSQL. It's kind of self-documenting, don'y you think? :-) I am, however, open to suggestions to a better alternative if one can be offered. I am, however, open to suggestions to a better alternative if one can be offered. ___ | Billy G. Allie| Domain: [EMAIL PROTECTED] | /| | 7436 Hartwell | Compuserve: 76337,2061 |-/-|- | Dearborn, MI 48126| MSN...: [EMAIL PROTECTED] |/ |LLIE | (313) 582-1540|
[GENERAL] Re: [HACKERS] My new job
At 01:02 PM 10/10/00 -0400, Tom Lane wrote: Bottom line is we're not sure what to do now. Opinions from the floor, anyone? Yeah, quit worrying and work your collective butts off on 7.1 and 7.2 :) Seriously...the core group is obviously committed to PG, and appear to be folks of integrity. We all will benefit by your working on PG full time while being paid enough so you can eat, drink, and be merry, too. - Don Baccus, Portland OR [EMAIL PROTECTED] Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Service and other goodies at http://donb.photo.net.
[HACKERS] calling PQendcopy() without blocking.
At times I need to call PQendcopy, how to I determine that it won't block me waiting for output from the backend? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
[HACKERS] Problem specifying limit in select inside insert.
Hello, I have quite strange behavior of the following SQL: insert into address (cid,email) select distinct '49'::int,member.email from member imit 1 ; It should insert just 1 record. But it insert all recodrs which will be selected by subselect... What's wrong with this SQL? Or this is a bug? If it is a bug... How to fix it (patch, workaround...) Thanks in advance. -- Sincerely Yours, Denis Perchine -- E-Mail: [EMAIL PROTECTED] HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 --
