Re: [HACKERS] big text field - message type 0x44
Tom Lane [EMAIL PROTECTED] writes: Tomas Berndtsson [EMAIL PROTECTED] writes: After it tries again, it always gets error from recv() for some reason that I don't know. I also don't understand why errno is set to ENOTTY at this point, that makes no sense at all. Are you sure it is set? Try setting errno=0 just before recv() (inside the retry loop). Maybe recv() is neglecting to set it in this case. Indeed you were right in this. But, if I added -D_REENTRANT to the Makefile for libpq, it started to set it. If libpq should be thread safe, I believe it should be compiled with -D_REENTRANT. When I did this, recv still returns error, but now sets errno to EAGAIN, so pqReadData() returns 1, giving the same result as removing the if-statement that does the try again thing. By skipping the trying again if-statement, pqReadData() will always return proper data, and let the calling function deal with the fact that there is more data to be read. I have no confidence in this. If the calling function comes back for more data, why wouldn't the recv() fail the same way? A few more instructions in between shouldn't change its behavior, one would think. No, I agree it sounds strange. I still haven't figured out why recv fails after the goto, but not when calling the function again. Tomas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
-Original Message- From: Lamar Owen [mailto:[EMAIL PROTECTED]] Sent: 05 December 2002 04:23 To: PostgreSQL-development Subject: Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group However, I seriously question the need in the long term for our sites to be as fractured as they are. Good grief! We've got advocacy.postgresql.org, techdocs.postgresql.org, odbc.postgresql.org, gborg.postgresql.org, developer.postgresql.org, jdbc.postgresql.org, etc. Oh, and we also have www.postgresql.org on the side? I think not. Oh, and they are fractured in their styles -- really, guys, we need a unified style here. Thats what we're working on. We've designed a new portal to all the sites. That's go live soon and then we'll start rationalising what's left. I'm already (admittedly slowly) deprecating odbc.postgresql.org. Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Shrinkwrap Windows Product, any issues? Anyone? (postmaster windows shell)
I am working on getting a shrink-wrapped version of PostgreSQL for WindowsCurrently it installs a customized version of Cygwin, PostgreSQL 7.2.3, cygipc, psqlodbc, and pgadminIII currently have the setup done. Cool :) I'm now working on postmaster windows shell. It's not finished yet but main things work. Funcionality implemented now is : Console redirection for capture output from postmaster Starting-stoping postmaster Choose for shutdown mode System tray icon Postmaster options are read from registry -postmaster path -datadir -additional options Funcionality not implementedyet, but planned: Writing captured output from postmaster to log file Options setup dialog Edit pg_hba.conf ??? Application is MFC free pure windows API (compiler:gcc-mingw, Dev-C++ IDE) . Here is the screenshot I also be GLAD to read about plans for native windows port in 7.4. If anyone is interested i can post source code, or maybe this firrst steps can go to gborg as a separate project i'm not sure yet. PS: Excuse me for my english, I'm better in C :)
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
On Wed, 4 Dec 2002 [EMAIL PROTECTED] wrote: It is unfortunate that it is almost impossible to have a marketing group without there being some wilful blinders involved; it's vital for there to be some technical involvement in the marketing group to pop whatever bubbles they grow that are woefully wrong. But even if it operates with some occasional lack of /real/ vision, it's necessary to have a marketing group... And, for the most part, those that are -advocacy are techies that wish to contribute as they can, but don't have the knowledge/time to dedicate to actual code ... Bruce is kinda quiet, but both he and I are on that list, and I read (and imagine Bruce does to) pretty much everything that goes through ... but, again, these aren't 'marketing droids' we have over there, but techies that are using the software and have an idea of her limitations and benefits ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
On Wed, 4 Dec 2002, Lamar Owen wrote: However, I seriously question the need in the long term for our sites to be as fractured as they are. Good grief! We've got advocacy.postgresql.org, techdocs.postgresql.org, odbc.postgresql.org, gborg.postgresql.org, developer.postgresql.org, jdbc.postgresql.org, etc. Oh, and we also have www.postgresql.org on the side? I think not. Oh, and they are fractured in their styles -- really, guys, we need a unified style here. Ummm, actually, we have: advocacy, techdocs, gborg, developer, archives, jobs note that altho they are seperate URLs, the end result is going to be that http://www.postgresql.org we become the town square of sorts, which should be real soon now ... jdbc/odbc are 'project sites' off of gborg, similar to what sourceforge provides ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
On Thu, 5 Dec 2002, Scott Lamb wrote: Is this list the appropriate place to discuss the websites? or should I take it to -advocacy? My impression here is that the two sites are maintained separately and the people involved haven't interacted very much. Is that accurate or no? Expect some major changes coming down the pipe ... http://www.postgresql.org is in its final stages of a major face lift ... the informatoin that iscurrently on that site, Vince is in the process of doing a major face lift on, but as it is now, I guess its been a veritible nightmare for him to really add anyting to it ... Once we announce the new http://www.postgresql.org (hopefully this coming week *cross fingers*), then start bombarding us with problems :) Note that for the web site development effort itself, there is a closed list with about a dozen or so of us on it ... the -advocacy list is meant to be open, with its focus reflected on the advocacy web site itself ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] 7.4 - TODO : IpcSemaphoreCreate: No space left on device
This error is accompanied by a suggestion to change SEMMNI or SEMMNS. In this case, that suggestion is not appropriate. Read below for the scenario. Suggestion: Can we modify the error message to include checking for a running postmaster? Reasoning: During my dbinit, I found the following error message. # su -l pgsql -c initdb The files belonging to this database system will be owned by user pgsql. This user must also own the server process. The database cluster will be initialized with locale C. creating directory /usr/local/pgsql/data... ok creating directory /usr/local/pgsql/data/base... ok creating directory /usr/local/pgsql/data/global... ok creating directory /usr/local/pgsql/data/pg_xlog... ok creating directory /usr/local/pgsql/data/pg_clog... ok creating template1 database in /usr/local/pgsql/data/base/1... IpcSemaphoreCreate: semget(key=1, num=17, 03600) failed: No space left on device This error does *not* mean that you have run out of disk space. It occurs when either the system limit for the maximum number of semaphore sets (SEMMNI), or the system wide maximum number of semaphores (SEMMNS), would be exceeded. You need to raise the respective kernel parameter. Alternatively, reduce PostgreSQL's consumption of semaphores by reducing its max_connections parameter (currently 1). The PostgreSQL Administrator's Guide contains more information about configuring your system for PostgreSQL. initdb failed. Removing /usr/local/pgsql/data. ### Here's what happened: I removed the old installs of pg (pkg_delete postgresql-7.2.3 pkg_delete postgresql-devel-7.3.rc1 ; this is a FreeBSD box), then installed 7.3. But I did not first stop the postmaster. Then I ran initdb, and the first message was: ### initdb: The directory /usr/local/pgsql/data exists but is not empty. If you want to create a new database system, either remove or empty the directory /usr/local/pgsql/data or run initdb with an argument other than /usr/local/pgsql/data. ### So I moved it out of the way: # mv /usr/local/pgsql/data /usr/local/pgsql/data.old That's when I encountered the message mentioned in the subject. The solution involved: # mv /usr/local/pgsql/data.old /usr/local/pgsql/data # /usr/local/etc/rc.d/010.pgsql.sh stop # mv /usr/local/pgsql/data /usr/local/pgsql/data.old # su -l pgsql -c initdb Then the initdb ran successfully. -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] big text field - message type 0x44
Tomas Berndtsson [EMAIL PROTECTED] writes: Indeed you were right in this. But, if I added -D_REENTRANT to the Makefile for libpq, it started to set it. If libpq should be thread safe, I believe it should be compiled with -D_REENTRANT. When I did this, recv still returns error, but now sets errno to EAGAIN, so pqReadData() returns 1, giving the same result as removing the if-statement that does the try again thing. Okay, so it seems -D_REENTRANT is the appropriate fix. We could either add that to the template/solaris file, or just add a note to FAQ_Solaris advising that it be added to the configure switches if people intend to use libpq in threaded programs. Is there any cost or downside to just adding it always in template/solaris? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
-Original Message- From: Scott Lamb [mailto:[EMAIL PROTECTED]] Sent: 05 December 2002 06:37 To: [EMAIL PROTECTED] Subject: Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group I'm volunteering to do work here. I could at the very least go through the sites and make a longer list of things like this that I notice. If they are public CVS somewhere, I can send patches. I saw that there's a http://wwwdevel.postgresql.org/. What's going on with that? Is there anything I can do to speed up its adoption? How will it affect the rest of the sites? That will be going live RSN as the first part of a re-org. Is this list the appropriate place to discuss the websites? or should I take it to -advocacy? My impression here is that the two sites are maintained separately and the people involved haven't interacted very much. Is that accurate or no? There are 2 groups of people -advocacy and the web developers. I have suggested to Marc that we need liason between the 2 groups, and better definition of who does what. FYI, -advocacy is an open list (afaik) and www is a closed group consisting of a few of us who actually do the work on the sites. There is a little overlap. Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] big text field - message type 0x44
Tom Lane [EMAIL PROTECTED] writes: Tomas Berndtsson [EMAIL PROTECTED] writes: Indeed you were right in this. But, if I added -D_REENTRANT to the Makefile for libpq, it started to set it. If libpq should be thread safe, I believe it should be compiled with -D_REENTRANT. When I did this, recv still returns error, but now sets errno to EAGAIN, so pqReadData() returns 1, giving the same result as removing the if-statement that does the try again thing. Okay, so it seems -D_REENTRANT is the appropriate fix. We could either add that to the template/solaris file, or just add a note to FAQ_Solaris advising that it be added to the configure switches if people intend to use libpq in threaded programs. Is there any cost or downside to just adding it always in template/solaris? Not that I know of. Some data (like errno) is made local for the thread, so I suppose it takes a little more memory and maybe more disk space, but else than that I don't think it affects much. But, then again, I'm not an expert at these things. Someone else might know more what the real difference is. Tomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] big text field - message type 0x44
Tom Lane writes: Okay, so it seems -D_REENTRANT is the appropriate fix. We could either add that to the template/solaris file, or just add a note to FAQ_Solaris advising that it be added to the configure switches if people intend to use libpq in threaded programs. Is there any cost or downside to just adding it always in template/solaris? However, _REENTRANT is not a Solarisism... On all (recent) UNIX systems it toggles on correct handling for thread specific instances of historically global variables (eg errno). It should be considered for all platforms if libpq is intended to be used from threaded programs. You'll probably find Tomas's code breaks on Linux too... Lee. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] 7.4 - TODO : alter table drop foreign key
We support alter table add foreign key. How about supporting alter table drop foreign key? - he said as he went to drop a foreign key -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] big text field - message type 0x44
Lee Kindness [EMAIL PROTECTED] writes: Tom Lane writes: Okay, so it seems -D_REENTRANT is the appropriate fix. We could either add that to the template/solaris file, or just add a note to FAQ_Solaris advising that it be added to the configure switches if people intend to use libpq in threaded programs. Is there any cost or downside to just adding it always in template/solaris? However, _REENTRANT is not a Solarisism... On all (recent) UNIX systems it toggles on correct handling for thread specific instances of historically global variables (eg errno). It should be considered for all platforms if libpq is intended to be used from threaded programs. I know libpq is officially non-threadsafe, but is there anything in there that would actually cause a problem, assuming either a connection per thread or proper locking on the application's part? Most of the data in the library seems to be per-connection... -Doug ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.4 - TODO : alter table drop foreign key
On Thu, 5 Dec 2002, Dan Langille wrote: We support alter table add foreign key. How about supporting alter table drop foreign key? - he said as he went to drop a foreign key It seems to work for me on my 7.3b2 system with alter table table drop constraint constraint name; ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] big text field - message type 0x44
Lee Kindness [EMAIL PROTECTED] writes: Tom Lane writes: Okay, so it seems -D_REENTRANT is the appropriate fix. We could either add that to the template/solaris file, or just add a note to FAQ_Solaris advising that it be added to the configure switches if people intend to use libpq in threaded programs. Is there any cost or downside to just adding it always in template/solaris? However, _REENTRANT is not a Solarisism... On all (recent) UNIX systems it toggles on correct handling for thread specific instances of historically global variables (eg errno). It should be considered for all platforms if libpq is intended to be used from threaded programs. You'll probably find Tomas's code breaks on Linux too... Actually, I've tried it in Linux, and it works there. Might be that the recv() doesn't return -1 when trying again in Linux. In that case, for this particular problem, it wouldn't matter if it's reentrant or not. Tomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] big text field - message type 0x44
Doug McNaught [EMAIL PROTECTED] writes: Lee Kindness [EMAIL PROTECTED] writes: Tom Lane writes: Okay, so it seems -D_REENTRANT is the appropriate fix. We could either add that to the template/solaris file, or just add a note to FAQ_Solaris advising that it be added to the configure switches if people intend to use libpq in threaded programs. Is there any cost or downside to just adding it always in template/solaris? However, _REENTRANT is not a Solarisism... On all (recent) UNIX systems it toggles on correct handling for thread specific instances of historically global variables (eg errno). It should be considered for all platforms if libpq is intended to be used from threaded programs. I know libpq is officially non-threadsafe, but is there anything in there that would actually cause a problem, assuming either a connection per thread or proper locking on the application's part? Most of the data in the library seems to be per-connection... The documentation states: libpq is thread-safe as of PostgreSQL 7.0, so long as no two threads attempt to manipulate the same PGconn object at the same time. Tomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.4 - TODO : alter table drop foreign key
On 5 Dec 2002 at 8:20, Stephan Szabo wrote: On Thu, 5 Dec 2002, Dan Langille wrote: We support alter table add foreign key. How about supporting alter table drop foreign key? - he said as he went to drop a foreign key It seems to work for me on my 7.3b2 system with alter table table drop constraint constraint name; How was that FK added? How did you determine the constraint name? -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 7.4 - TODO : alter table drop foreign key
On 5 Dec 2002 at 8:20, Stephan Szabo wrote: On Thu, 5 Dec 2002, Dan Langille wrote: We support alter table add foreign key. How about supporting alter table drop foreign key? - he said as he went to drop a foreign key It seems to work for me on my 7.3b2 system with alter table table drop constraint constraint name; Premature send.. sorry How was that FK added? How did you determine the constraint name? How would you do that if the FK was added with the following syntax? alter table table add foreign key (column) references othertable (othercolumn) on update cascade on delete cascade; -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.4 - TODO : alter table drop foreign key
On Thu, 5 Dec 2002, Dan Langille wrote: On 5 Dec 2002 at 8:20, Stephan Szabo wrote: On Thu, 5 Dec 2002, Dan Langille wrote: We support alter table add foreign key. How about supporting alter table drop foreign key? - he said as he went to drop a foreign key It seems to work for me on my 7.3b2 system with alter table table drop constraint constraint name; Premature send.. sorry How was that FK added? How did you determine the constraint name? alter table table add constraint name foreign key ... How would you do that if the FK was added with the following syntax? alter table table add foreign key (column) references othertable (othercolumn) on update cascade on delete cascade; IIRC, the constraint will get an automatic name of the form $n in such cases. I believe if you do a \d on the table, it gives the name in the constraint definitions (on one of mine i get: Foreign Key constraints: $1 FOREIGN KEY (a) REFERENCES qqq(a) ON UPDATE CASCADE ON DELETE NO ACTION Where $1 is the name of the constraint. ---(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: [HACKERS] 7.4 - TODO : alter table drop foreign key
On 5 Dec 2002 at 8:44, Stephan Szabo wrote: On Thu, 5 Dec 2002, Dan Langille wrote: On 5 Dec 2002 at 8:20, Stephan Szabo wrote: On Thu, 5 Dec 2002, Dan Langille wrote: We support alter table add foreign key. How about supporting alter table drop foreign key? - he said as he went to drop a foreign key It seems to work for me on my 7.3b2 system with alter table table drop constraint constraint name; Premature send.. sorry How was that FK added? How did you determine the constraint name? alter table table add constraint name foreign key ... How would you do that if the FK was added with the following syntax? alter table table add foreign key (column) references othertable (othercolumn) on update cascade on delete cascade; IIRC, the constraint will get an automatic name of the form $n in such cases. I believe if you do a \d on the table, it gives the name in the constraint definitions (on one of mine i get: Foreign Key constraints: $1 FOREIGN KEY (a) REFERENCES qqq(a) ON UPDATE CASCADE ON DELETE NO ACTION Where $1 is the name of the constraint. Thanks. In my 7.2.3 database, the table in question has: Primary key: watch_list_staging_pkey Check constraints: watch_list_stag_from_watch_list ((from_watch_list = 't'::bool) OR (from_watch_list = 'f'::bool)) watch_list_stagin_from_pkg_info ((from_pkg_info = 't'::bool) OR (from_pkg_info = 'f'::bool)) Triggers: RI_ConstraintTrigger_4278482, RI_ConstraintTrigger_4278488 No mention of FK constraints. -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.4 - TODO : alter table drop foreign key
On 5 Dec 2002 at 11:47, Dan Langille wrote: On 5 Dec 2002 at 8:44, Stephan Szabo wrote: On Thu, 5 Dec 2002, Dan Langille wrote: On 5 Dec 2002 at 8:20, Stephan Szabo wrote: On Thu, 5 Dec 2002, Dan Langille wrote: We support alter table add foreign key. How about supporting alter table drop foreign key? - he said as he went to drop a foreign key It seems to work for me on my 7.3b2 system with alter table table drop constraint constraint name; Premature send.. sorry How was that FK added? How did you determine the constraint name? alter table table add constraint name foreign key ... How would you do that if the FK was added with the following syntax? alter table table add foreign key (column) references othertable (othercolumn) on update cascade on delete cascade; IIRC, the constraint will get an automatic name of the form $n in such cases. I believe if you do a \d on the table, it gives the name in the constraint definitions (on one of mine i get: Foreign Key constraints: $1 FOREIGN KEY (a) REFERENCES qqq(a) ON UPDATE CASCADE ON DELETE NO ACTION Where $1 is the name of the constraint. Thanks. In my 7.2.3 database, the table in question has: Primary key: watch_list_staging_pkey Check constraints: watch_list_stag_from_watch_list ((from_watch_list = 't'::bool) OR (from_watch_list = 'f'::bool)) watch_list_stagin_from_pkg_info ((from_pkg_info = 't'::bool) OR (from_pkg_info = 'f'::bool)) Triggers: RI_ConstraintTrigger_4278482, RI_ConstraintTrigger_4278488 No mention of FK constraints. Found the solution: drop trigger RI_ConstraintTrigger_4278488 on watch_list_staging; Given that the FK in question did not have a name to start with, I concede that it would be difficult to code DROP FOREIGN KEY. What about supporting ALTER TABLE table ADD FOREIGN KEY keyname ... which at present we don't? That would then make dropping the FK a simple coding issue? -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
On Thursday 05 December 2002 09:37, Marc G. Fournier wrote: On Wed, 4 Dec 2002, Lamar Owen wrote: However, I seriously question the need in the long term for our sites to be as fractured as they are. Good grief! We've got note that altho they are seperate URLs, the end result is going to be that http://www.postgresql.org we become the town square of sorts, which should be real soon now ... jdbc/odbc are 'project sites' off of gborg, similar to what sourceforge provides ... Glad to hear this. One question: is there any particular reason the www list is closed? Just curious -- reading archives of this list, or getting a digest or this list, even in a read-only manner, might alleviate some misconceptions. Those who care can at least read what's planned for the web site. As far as advocacy is concerned, I made a conscious decision to not read that list -- I don't need to be convinced to use PostgreSQL. :-). Nor am I necessarily a good 'advocacy' person..my 'convincing' many times comes across much different from what I meant. So I don't read that list. Can you (or Vince) distill a roadmap for the website and post here, on hackers? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.4 - TODO : alter table drop foreign key
On Thu, 5 Dec 2002, Dan Langille wrote: Found the solution: drop trigger RI_ConstraintTrigger_4278488 on watch_list_staging; Actually there are three triggers for the constraint. You may have dangling triggers on the other table of the constraint. It's one on the table the constraint's defined on and two on the referenced table. Given that the FK in question did not have a name to start with, I concede that it would be difficult to code DROP FOREIGN KEY. What about supporting ALTER TABLE table ADD FOREIGN KEY keyname ... which at present we don't? That would then make dropping the FK a simple coding issue? ISTM, that's ALTER TABLE table ADD CONSTRAINT name FOREIGN KEY ... which should be there in any 7.x. And the drop constraint for foreign keys (and the \d display stuff) is new in 7.3. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.4 - TODO : alter table drop foreign key
On 5 Dec 2002 at 9:02, Stephan Szabo wrote: On Thu, 5 Dec 2002, Dan Langille wrote: Found the solution: drop trigger RI_ConstraintTrigger_4278488 on watch_list_staging; Actually there are three triggers for the constraint. You may have dangling triggers on the other table of the constraint. It's one on the table the constraint's defined on and two on the referenced table. Given that the FK in question did not have a name to start with, I concede that it would be difficult to code DROP FOREIGN KEY. What about supporting ALTER TABLE table ADD FOREIGN KEY keyname ... which at present we don't? That would then make dropping the FK a simple coding issue? ISTM, that's ALTER TABLE table ADD CONSTRAINT name FOREIGN KEY ... which should be there in any 7.x. Agreed. But the syntax is different. If we are supporting ALTER TABLE table ADD FOREIGN KEY without a name, why not support it with a name? And the drop constraint for foreign keys (and the \d display stuff) is new in 7.3. That's going to be much more useful. I installed 7.3 for testing this morning. Looking at it now, I no longer see a need for a DROP FOREIGN KEY. Thank you. -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.4 - TODO : alter table drop foreign key
On Thu, 5 Dec 2002, Dan Langille wrote: On 5 Dec 2002 at 9:02, Stephan Szabo wrote: On Thu, 5 Dec 2002, Dan Langille wrote: Found the solution: drop trigger RI_ConstraintTrigger_4278488 on watch_list_staging; Actually there are three triggers for the constraint. You may have dangling triggers on the other table of the constraint. It's one on the table the constraint's defined on and two on the referenced table. Given that the FK in question did not have a name to start with, I concede that it would be difficult to code DROP FOREIGN KEY. What about supporting ALTER TABLE table ADD FOREIGN KEY keyname ... which at present we don't? That would then make dropping the FK a simple coding issue? ISTM, that's ALTER TABLE table ADD CONSTRAINT name FOREIGN KEY ... which should be there in any 7.x. Agreed. But the syntax is different. If we are supporting ALTER TABLE table ADD FOREIGN KEY without a name, why not support it with a name? When we talk about ALTER TABLE ADD FOREIGN KEY we're being imprecise, so I think that might be why we're talking past each other here. Technically the syntax in question is: ALTER TABLE table ADD table constraint definition where CONSTRAINT name is an optional leading clause in a table constraint definition. ADD FOREIGN KEY is a shorthand for a foreign key constraint (technically unnamed). Thus you can also say things like: ALTER TABLE table ADD CONSTRAINT blah CHECK (foo!=0); to make a named check constraint. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.4 - TODO : alter table drop foreign key
On 5 Dec 2002 at 9:31, Stephan Szabo wrote: When we talk about ALTER TABLE ADD FOREIGN KEY we're being imprecise, so I think that might be why we're talking past each other here. Technically the syntax in question is: ALTER TABLE table ADD table constraint definition where CONSTRAINT name is an optional leading clause in a table constraint definition. ADD FOREIGN KEY is a shorthand for a foreign key constraint (technically unnamed). Understood. What about allowing a named foreign key? I haven't checked the RFCs Thus you can also say things like: ALTER TABLE table ADD CONSTRAINT blah CHECK (foo!=0); to make a named check constraint. Understood. -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Shrinkwrap Windows Product, any issues? Anyone? (postmaster windows
Hey this is a cool project. I have been thinking doing the exact ame thing, the console Window of 2K/XP just kills the daemon, yuck. What can I do to help? Igor Georgiev wrote: I am working on getting a shrink-wrapped version of PostgreSQL for Windows Currently it installs a customized version of Cygwin, PostgreSQL 7.2.3, cygipc, psqlodbc, and pgadminII I currently have the setup done. Cool :) I'm now working on postmaster windows shell. It's not finished yet but main things work. Funcionality implemented now is : Console redirection for capture output from postmaster Starting-stoping postmaster Choose for shutdown mode System tray icon Postmaster options are read from registry -postmaster path -datadir -additional options Funcionality not implemented yet, but planned : Writing captured output from postmaster to log file Options setup dialog Edit pg_hba.conf ??? Application is MFC free pure windows API (compiler:gcc-mingw, Dev-C++ IDE) . Here is the screenshot I also be GLAD to read about plans for native windows port in 7.4. If anyone is interested i can post source code, or maybe this firrst steps can go to gborg as a separate project i'm not sure yet. PS: Excuse me for my english, I'm better in C :)
Re: [HACKERS] 7.4 - TODO : alter table drop foreign key
On Thu, 5 Dec 2002, Dan Langille wrote: On 5 Dec 2002 at 9:31, Stephan Szabo wrote: When we talk about ALTER TABLE ADD FOREIGN KEY we're being imprecise, so I think that might be why we're talking past each other here. Technically the syntax in question is: ALTER TABLE table ADD table constraint definition where CONSTRAINT name is an optional leading clause in a table constraint definition. ADD FOREIGN KEY is a shorthand for a foreign key constraint (technically unnamed). Understood. What about allowing a named foreign key? I haven't checked the RFCs Here's a part of what SQL92 (draft) has to say about table constraint definitions: table constraint definition ::= [ constraint name definition ] table constraint [ constraint attributes ] table constraint ::= unique constraint definition | referential constraint definition | check constraint definition constraint name definition ::= CONSTRAINT constraint name referential constraint definition ::= FOREIGN KEY left paren referencing columns right paren references specification 11.6 Syntax Rules 2) If constraint name definition is not specified, then a con- straint name definition that contains an implementation- dependent constraint name is implicit. The assigned con- straint name shall obey the Syntax Rules of an explicit con- straint name. In our case, the implementation dependent naming scheme is I believe $n where n is the maximum one already there for that table +1 I would guess. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.4 - TODO : alter table drop foreign key
On 5 Dec 2002 at 9:51, Stephan Szabo wrote: On Thu, 5 Dec 2002, Dan Langille wrote: On 5 Dec 2002 at 9:31, Stephan Szabo wrote: When we talk about ALTER TABLE ADD FOREIGN KEY we're being imprecise, so I think that might be why we're talking past each other here. Technically the syntax in question is: ALTER TABLE table ADD table constraint definition where CONSTRAINT name is an optional leading clause in a table constraint definition. ADD FOREIGN KEY is a shorthand for a foreign key constraint (technically unnamed). Understood. What about allowing a named foreign key? I haven't checked the RFCs Here's a part of what SQL92 (draft) has to say about table constraint definitions: table constraint definition ::= [ constraint name definition ] table constraint [ constraint attributes ] table constraint ::= unique constraint definition | referential constraint definition | check constraint definition constraint name definition ::= CONSTRAINT constraint name referential constraint definition ::= FOREIGN KEY left paren referencing columns right paren references specification 11.6 Syntax Rules 2) If constraint name definition is not specified, then a con- straint name definition that contains an implementation- dependent constraint name is implicit. The assigned con- straint name shall obey the Syntax Rules of an explicit con- straint name. In our case, the implementation dependent naming scheme is I believe $n where n is the maximum one already there for that table +1 I would guess. Thanks. I guess I should rename my thread to 7.4 - TODO : allow constraint names when using the ALTER TABLE table ADD FOREIGN KEY syntax. -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] 7.3 pg_relcheck oddness
I am poking around at upgrading PostGIS to work with version 7.3. So far, the changes seem relatively minor. There is one odd quirk though. Having gotten the PostGIS types and index bindings loaded, and having loaded a table full of spatial data, trying to do \d thetable returns ERROR: Relation pg_relcheck does not exist And when I check, lo and behold, it does *not* exist! \d still works on all normal tables however. I checked in the 7.2 instance, and pg_relcheck does exist, but has no entries in it. Simply adding an empty pg_relcheck to my 7.3 instance using the old 7.2 definitions caused \d to start working again on my spatial table. P. -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(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: [HACKERS] big text field - message type 0x44
Lee Kindness [EMAIL PROTECTED] writes: Tom Lane writes: Okay, so it seems -D_REENTRANT is the appropriate fix. However, _REENTRANT is not a Solarisism... On all (recent) UNIX systems it toggles on correct handling for thread specific instances of historically global variables (eg errno). It should be considered for all platforms if libpq is intended to be used from threaded programs. Now that I think about it, what that macro is probably really doing is switching the code from looking at a static errno variable to looking at a per-thread variable. So in fact -D_REENTRANT would be correct if you intended to link with a thread-aware libc, and wrong if you intended to link with a non-aware libc. (Is there such a thing as a non-threaded implementation of libc on the platforms where -D_REENTRANT does anything?) If this analysis is right then I think we should *not* force _REENTRANT; it will have to be up to users to choose the mechanism they want to use in their programs. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.4 - TODO : alter table drop foreign key
Thanks. I guess I should rename my thread to 7.4 - TODO : allow constraint names when using the ALTER TABLE table ADD FOREIGN KEY syntax. You can do that now. ALTER TABLE table ADD CONSTRAINT const FOREIGN KEY -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] 7.3 pg_relcheck oddness
On further investigation, the problem is related to using a 7.2 psql against a 7.3 backend. The \d from the 7.2 psql is not compatible with the 7.3 backend in the case of tables with non-standard types apparently. P. Paul Ramsey wrote: I am poking around at upgrading PostGIS to work with version 7.3. So far, the changes seem relatively minor. There is one odd quirk though. Having gotten the PostGIS types and index bindings loaded, and having loaded a table full of spatial data, trying to do \d thetable returns ERROR: Relation pg_relcheck does not exist And when I check, lo and behold, it does *not* exist! \d still works on all normal tables however. I checked in the 7.2 instance, and pg_relcheck does exist, but has no entries in it. Simply adding an empty pg_relcheck to my 7.3 instance using the old 7.2 definitions caused \d to start working again on my spatial table. P. -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.4 - TODO : alter table drop foreign key
Dan Langille wrote: On 5 Dec 2002 at 11:47, Dan Langille wrote: Primary key: watch_list_staging_pkey Check constraints: watch_list_stag_from_watch_list ((from_watch_list = 't'::bool) OR (from_watch_list = 'f'::bool)) watch_list_stagin_from_pkg_info ((from_pkg_info = 't'::bool) OR (from_pkg_info = 'f'::bool)) Triggers: RI_ConstraintTrigger_4278482, RI_ConstraintTrigger_4278488 No mention of FK constraints. Found the solution: drop trigger RI_ConstraintTrigger_4278488 on watch_list_staging; You should now go to the table this RI constraint was referring to and delete the two triggers in there as well. They will still be checking for deletions and updates. Look for something like RI_ConstraintTrigger_4278490 RI_ConstraintTrigger_4278492 and with the associated procedure RI_FKey_noaction_del and RI_FKey_noaction_upd BTW, the rhdb-admin program can drop the constraints for you, even the unnamed ones on backends 7.2 up. You can download it from: http://sources.redhat.com/rhdb Of course, now that you broke the set of triggers for this FK constraint you'll still need to drop the other ones by hand. But the tool at least will show you the column and table involved so it will be easier to identify the two you have to get rid of. Regards, Fernando -- Fernando Nasser Red Hat - Toronto E-Mail: [EMAIL PROTECTED] 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib/ltree patches
Don't do it! It's a wrong patch. Dan will prepare correct patch (with other
changes).
Bruce Momjian wrote:
Dan, is this ready to be applied to CVS?
---
Dan Langille wrote:
I have been looking at contrib/ltree in the PostgreSQL repository. I've
modified the code to allow / as a node delimiter instead of . which is the
default.
Below are the patches to make this change. I have also moved the
delimiter to a DEFINE so that other customizations are easily done. This
is a work in progress.
My thanks to DarbyD for assistance.
cheers
--- ltree.h.orig Tue Nov 26 18:57:58 2002
+++ ltree.h Tue Nov 26 20:16:40 2002
@@ -6,6 +6,8 @@
#include utils/palloc.h
#include utils/builtins.h
+#define NODE_DELIMITER '/'
+
typedef struct
{
uint8 len;
@@ -88,7 +90,7 @@
#ifndef abs
#define abs(a) ((a) (0) ? -(a) : (a))
#endif
-#define ISALNUM(x) ( isalnum((unsigned int)(x)) || (x) == '_' )
+#define ISALNUM(x) ( isalnum((unsigned int)(x)) || (x) == '_' || (x) == NODE_DELIMITER )
/* full text query */
--- ltree_io.c Tue Nov 26 20:23:45 2002
+++ ltree_io.c.orig Tue Nov 26 18:57:26 2002
@@ -48,7 +48,7 @@
ptr = buf;
while (*ptr)
{
- if (*ptr == NODE_DELIMITER)
+ if (*ptr == '.')
num++;
ptr++;
}
@@ -69,7 +69,7 @@
}
else if (state == LTPRS_WAITDELIM)
{
- if (*ptr == NODE_DELIMITER)
+ if (*ptr == '.')
{
lptr-len = ptr - lptr-start;
if (lptr-len 255)
@@ -131,7 +131,7 @@
{
if (i != 0)
{
- *ptr = NODE_DELIMITER;
+ *ptr = '.';
ptr++;
}
memcpy(ptr, curlevel-name, curlevel-len);
@@ -181,7 +181,7 @@
ptr = buf;
while (*ptr)
{
- if (*ptr == NODE_DELIMITER)
+ if (*ptr == '.')
num++;
else if (*ptr == '|')
numOR++;
@@ -265,7 +265,7 @@
lptr-len, (int) (lptr-start - buf));
state = LQPRS_WAITVAR;
}
- else if (*ptr == NODE_DELIMITER)
+ else if (*ptr == '.')
{
lptr-len = ptr - lptr-start -
((lptr-flag LVAR_SUBLEXEM) ? 1 : 0) -
@@ -289,7 +289,7 @@
{
if (*ptr == '{')
state = LQPRS_WAITFNUM;
- else if (*ptr == NODE_DELIMITER)
+ else if (*ptr == '.')
{
curqlevel-low = 0;
curqlevel-high = 0x;
@@ -347,7 +347,7 @@
}
else if (state == LQPRS_WAITEND)
{
- if (*ptr == NODE_DELIMITER)
+ if (*ptr == '.')
{
state = LQPRS_WAITLEVEL;
curqlevel = NEXTLEV(curqlevel);
@@ -471,7 +471,7 @@
{
if (i != 0)
{
- *ptr = NODE_DELIMITER;
+ *ptr = '.';
ptr++;
}
if (curqlevel-numvar)
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
--
Teodor Sigaev
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] contrib/ltree patches
Thanks for asking. I have been diverted to other tasks and won't be
able to get back to this for a short while. The basics work (i.e.
population and simple compares) but I know for sure that certain
functions will not work now that we allow what were previously
operators to be part of the node name. In short, the code needs to
allow for operators to be escaped if they are part of the node name.
On 5 Dec 2002 at 0:54, Bruce Momjian wrote:
Dan, is this ready to be applied to CVS?
--
-
Dan Langille wrote:
I have been looking at contrib/ltree in the PostgreSQL repository.
I've modified the code to allow / as a node delimiter instead of .
which is the default.
Below are the patches to make this change. I have also moved the
delimiter to a DEFINE so that other customizations are easily done.
This is a work in progress.
My thanks to DarbyD for assistance.
cheers
--- ltree.h.origTue Nov 26 18:57:58 2002
+++ ltree.h Tue Nov 26 20:16:40 2002
@@ -6,6 +6,8 @@
#include utils/palloc.h
#include utils/builtins.h
+#defineNODE_DELIMITER '/'
+
typedef struct
{
uint8 len;
@@ -88,7 +90,7 @@
#ifndef abs
#define abs(a) ((a) (0) ? -(a) : (a))
#endif
-#define ISALNUM(x) ( isalnum((unsigned int)(x)) || (x) == '_' )
+#define ISALNUM(x) ( isalnum((unsigned int)(x)) || (x) == '_' ||
+#(x) == NODE_DELIMITER )
/* full text query */
--- ltree_io.c Tue Nov 26 20:23:45 2002
+++ ltree_io.c.orig Tue Nov 26 18:57:26 2002
@@ -48,7 +48,7 @@
ptr = buf;
while (*ptr)
{
- if (*ptr == NODE_DELIMITER)
+ if (*ptr == '.')
num++;
ptr++;
}
@@ -69,7 +69,7 @@
}
else if (state == LTPRS_WAITDELIM)
{
- if (*ptr == NODE_DELIMITER)
+ if (*ptr == '.')
{
lptr-len = ptr - lptr-start;
if (lptr-len 255)
@@ -131,7 +131,7 @@
{
if (i != 0)
{
- *ptr = NODE_DELIMITER;
+ *ptr = '.';
ptr++;
}
memcpy(ptr, curlevel-name, curlevel-len);
@@ -181,7 +181,7 @@
ptr = buf;
while (*ptr)
{
- if (*ptr == NODE_DELIMITER)
+ if (*ptr == '.')
num++;
else if (*ptr == '|')
numOR++;
@@ -265,7 +265,7 @@
lptr-len, (int) (lptr-start - buf));
state = LQPRS_WAITVAR;
}
- else if (*ptr == NODE_DELIMITER)
+ else if (*ptr == '.')
{
lptr-len = ptr - lptr-start -
((lptr-flag LVAR_SUBLEXEM) ? 1 : 0) -
@@ -289,7 +289,7 @@
{
if (*ptr == '{')
state = LQPRS_WAITFNUM;
- else if (*ptr == NODE_DELIMITER)
+ else if (*ptr == '.')
{
curqlevel-low = 0;
curqlevel-high = 0x;
@@ -347,7 +347,7 @@
}
else if (state == LQPRS_WAITEND)
{
- if (*ptr == NODE_DELIMITER)
+ if (*ptr == '.')
{
state = LQPRS_WAITLEVEL;
curqlevel = NEXTLEV(curqlevel);
@@ -471,7 +471,7 @@
{
if (i != 0)
{
- *ptr = NODE_DELIMITER;
+ *ptr = '.';
ptr++;
}
if (curqlevel-numvar)
---(end of
broadcast)--- TIP 4: Don't 'kill -9' the
postmaster
--
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
--
Dan Langille : http://www.langille.org/
---(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: [HACKERS] PQnotifies() in 7.3 broken?
Bruce Momjian writes: Tom Lane wrote: Lee Kindness [EMAIL PROTECTED] writes: Perhaps the .so name should have been updated for PostgreSQL 7.3? It should have been. If it wasn't, that was a serious oversight. Not sure if we should change it in 7.3.1 or not, though; it may be too late for that. Any thoughts out there? Seems I did forget. I always update the minor for a major release, but when development starts, and I seem to have forgotten for 7.3. Sorry. Personally I think automatically updating the version numbers is as bad as not doing it at all - it misses the point. The version numbers in shared library filenames denote binary compatibilty, if the /public/ API changes then the version number really must be incremented. If the version increments without any associated API changes then it's just a PITA for developers and products linking to the PostgreSQL libraries! It forces recompilation when there is not really a need. Lee. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
On Thu, 5 Dec 2002, Philip Warner wrote: At 05:48 PM 4/12/2002 -0800, Christopher Kings-Lynne wrote: Lack of marketing is one of Postgres's major problems. What are the consequences of the problem? Well, I'd have to say the major one is a difficult in increasing our user base, as ppl like MySQL are making sure they are heard whenever they add something new that we've had for years ... If that is what we want, then fine. But I don't want to see any part of the development effort distorted or the existing user base inconvenienced in an effort to purely gain that market share. I usually associate increased marketing with decreased quality, and I think the causality works *both* ways. That is what we want, and the efforts in no way are meant to undermine/distort anything ... go to archives.postgresql.org and read through the threads to get a feel ... its not a closed/hidden list by any means ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
On Thu, 2002-12-05 at 03:28, Dave Page wrote: www is a closed group consisting of a few of us who actually do the work on the sites. This is one of the primary reasons the sites are so fractured. We have 4 different mailing lists for website development (and I'm not counting advocacy as one of those) and the folks maintaining those lists seem to be against letting anyone into their fiefdoms. Robert Treat ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
Marc G. Fournier wrote: On Wed, 4 Dec 2002 [EMAIL PROTECTED] wrote: It is unfortunate that it is almost impossible to have a marketing group without there being some wilful blinders involved; it's vital for there to be some technical involvement in the marketing group to pop whatever bubbles they grow that are woefully wrong. But even if it operates with some occasional lack of /real/ vision, it's necessary to have a marketing group... And, for the most part, those that are -advocacy are techies that wish to contribute as they can, but don't have the knowledge/time to dedicate to actual code ... Bruce is kinda quiet, but both he and I are on that list, and I read (and imagine Bruce does to) pretty much everything that goes through ... but, again, these aren't 'marketing droids' we have over there, but techies that are using the software and have an idea of her limitations and benefits ... Yes, I have been way too quiet. I am trying to carve out time before starting on 7.4 work, but it seems stuff keeps coming up. I have updated the developers page with company names, and Vince is going to integrate that. My next step is to split out my advocacy mailbox and start shooting out content for the advocacy site. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 7.4 - TODO : alter table drop foreign key
On 5 Dec 2002 at 14:17, Fernando Nasser wrote: Dan Langille wrote: On 5 Dec 2002 at 11:47, Dan Langille wrote: drop trigger RI_ConstraintTrigger_4278488 on watch_list_staging; You should now go to the table this RI constraint was referring to and delete the two triggers in there as well. They will still be checking for deletions and updates. Look for something like RI_ConstraintTrigger_4278490 RI_ConstraintTrigger_4278492 and with the associated procedure RI_FKey_noaction_del and RI_FKey_noaction_upd Oh thank you! I didn't know about those. FWIW, I've just documented this exercise at http://www.freebsddiary.org/postgresql-dropping- constraints.php so corrections are most welcome. BTW, the rhdb-admin program can drop the constraints for you, even the unnamed ones on backends 7.2 up. You can download it from: http://sources.redhat.com/rhdb Thanks. I hope to check that out one day. Of course, now that you broke the set of triggers for this FK constraint you'll still need to drop the other ones by hand. But the tool at least will show you the column and table involved so it will be easier to identify the two you have to get rid of. I did the identification by hand and fixed it up that way. Hopefully there's nothing else in there I've done wrong. -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 7.4 - TODO : alter table drop foreign key
Thanks. I guess I should rename my thread to 7.4 - TODO : allow constraint names when using the ALTER TABLE table ADD FOREIGN KEY syntax. You can do that now. ALTER TABLE table ADD CONSTRAINT const FOREIGN KEY That I know. That syntax is radically different from that proposed. Isn't it identical? The CONSTRAINT const is SQL standard optional clause for all commands that add constraints. Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 7.4 - TODO : alter table drop foreign key
On 5 Dec 2002 at 11:52, Christopher Kings-Lynne wrote: Thanks. I guess I should rename my thread to 7.4 - TODO : allow constraint names when using the ALTER TABLE table ADD FOREIGN KEY syntax. You can do that now. ALTER TABLE table ADD CONSTRAINT const FOREIGN KEY That I know. That syntax is radically different from that proposed. I take back the adjective radical Isn't it identical? The CONSTRAINT const is SQL standard optional clause for all commands that add constraints. Except that one is ADD CONSTRAINT, the other is an ADD FOREIGN KEY. They are similar in nature but different overall. -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.4 - TODO : alter table drop foreign key
Isn't it identical? The CONSTRAINT const is SQL standard optional clause for all commands that add constraints. Except that one is ADD CONSTRAINT, the other is an ADD FOREIGN KEY. They are similar in nature but different overall. I think you're getting a little confused here, Dan. http://www3.us.postgresql.org/users-lounge/docs/7.3/postgres/sql-altertable. html There is only one command for adding constraints to a table. It has this syntax: ALTER TABLE [ ONLY ] table [ * ] ADD table_constraint The table_constraint clause is defined like this (basically): [CONSTRAINT blah] (PRIMARY KEY or UNIQUE or FOREIGN KEY) ... So, the CONSTRAINT blah clause allows you to specify a name for any of the 3 types of constraint: primary key, unique or foreign key. There's nothing special about foreign keys in this case. If you don't put in the CONSTRAINT blah clause, you get an automatically assigned constraint name. Chris ---(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: [HACKERS] 7.4 - TODO : alter table drop foreign key
On Thu, 2002-12-05 at 14:52, Christopher Kings-Lynne wrote: Thanks. I guess I should rename my thread to 7.4 - TODO : allow constraint names when using the ALTER TABLE table ADD FOREIGN KEY syntax. You can do that now. ALTER TABLE table ADD CONSTRAINT const FOREIGN KEY That I know. That syntax is radically different from that proposed. Isn't it identical? The CONSTRAINT const is SQL standard optional clause for all commands that add constraints. Not to mention the same as the CREATE TABLE syntax for constraints that we already have. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] 7.3 pg_relcheck oddness
Paul Ramsey [EMAIL PROTECTED] writes: \d thetable returns ERROR: Relation pg_relcheck does not exist I think you are using a 7.2 psql with the 7.3 server. There will be quite a few problems with backslash commands in that combination (or the reverse), because of the extensive catalog changes in 7.3. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 7.4 - TODO : alter table drop foreign key
On 5 Dec 2002 at 12:09, Christopher Kings-Lynne wrote: Isn't it identical? The CONSTRAINT const is SQL standard optional clause for all commands that add constraints. Except that one is ADD CONSTRAINT, the other is an ADD FOREIGN KEY. They are similar in nature but different overall. I think you're getting a little confused here, Dan. http://www3.us.postgresql.org/users-lounge/docs/7.3/postgres/sql-altertable. html There is only one command for adding constraints to a table. It has this syntax: ALTER TABLE [ ONLY ] table [ * ] ADD table_constraint The table_constraint clause is defined like this (basically): [CONSTRAINT blah] (PRIMARY KEY or UNIQUE or FOREIGN KEY) ... So, the CONSTRAINT blah clause allows you to specify a name for any of the 3 types of constraint: primary key, unique or foreign key. There's nothing special about foreign keys in this case. If you don't put in the CONSTRAINT blah clause, you get an automatically assigned constraint name. Regardless of what is documented, the following is valid and works: ALTER TABLE slave ADD FOREIGN KEY (master_id) REFERENCES master (id) ON DELETE CASCADE; -- Dan Langille : http://www.langille.org/ ---(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: [HACKERS] 7.4 - TODO : alter table drop foreign key
Dan Langille [EMAIL PROTECTED] writes: You can do that now. ALTER TABLE table ADD CONSTRAINT const FOREIGN KEY That I know. That syntax is radically different from that proposed. So you're proposing we replace a SQL-spec-compliant syntax with one that is not? Why? 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
Re: [HACKERS] 7.4 - TODO : alter table drop foreign key
On 5 Dec 2002 at 15:36, Tom Lane wrote: Dan Langille [EMAIL PROTECTED] writes: You can do that now. ALTER TABLE table ADD CONSTRAINT const FOREIGN KEY That I know. That syntax is radically different from that proposed. So you're proposing we replace a SQL-spec-compliant syntax with one that is not? Why? If it's not compliant, I withdraw. -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Quick Help
Hi guys, Messing about with ADD COLUMN... I'm not certain how to re-evaluate the default expression for each row? How do I do this? I have access to raw_default and cooked_default it seems. Thanks, Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Shrinkwrap Windows Product, any issues? Anyone? (postmaster
Igor Georgiev wrote: snip I also be GLAD to read about plans for native windows port in 7.4. If anyone is interested i can post source code, or maybe this firrst steps can go to gborg as a separate project i'm not sure yet. Hi Igor, This would be a really good thing to get into GBorg as a project, so people could work on this through CVS. Would you like to register it as a project? Mark, do you feel it would be better to put your installer plus this together into one project on GBorg too? Not sure, it's just a thought. :-) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Shrinkwrap Windows Product, any issues? Anyone? (postmaster
Justin Clift wrote: Igor Georgiev wrote: snip I also be GLAD to read about plans for native windows port in 7.4. If anyone is interested i can post source code, or maybe this firrst steps can go to gborg as a separate project i'm not sure yet. Hi Igor, This would be a really good thing to get into GBorg as a project, so people could work on this through CVS. Would you like to register it as a project? Mark, do you feel it would be better to put your installer plus this together into one project on GBorg too? Not sure, it's just a thought. The installer is simply a script, the ino installer, and a strategy. I install enough Cygwin to run PostgreSQL, and a few batch files, I then compile that into an install file. No biggie. Igor's console program is cool, I was thinking of writing something just like it. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Q: unknown expression type 108 ?
Hi appended below is a simple database schema (which may not be a candidate for the next Nobel Prize for SQL Database Design, but represents enough of a production database to demonstrate the following problem). And that is: under 7.3 this statement: SELECT foo_id, thingy_name, bar_name FROM foo_view, bar WHERE bar_id=foo_bar_id produces the desired results. This however: SELECT foo_id, thingy_name, bar_name FROM foo_view INNER JOIN bar ON bar_id=foo_bar_id produces ERROR: ExecEvalExpr: unknown expression type 108 The latter statement does however work in 7.1.3 with no apparent problems. Question: what does unknown expression type 108 mean and why should it suddenly occur in 7.3? A bit of Googling reveals the same message occurs when using subselects in constraints, but that doesn't seem related to this case. Ian Barwick [EMAIL PROTECTED] -- sample DB for unknown expression type 108 error CREATE TABLE a_thingy ( a_id INT, a_firstname VARCHAR(64), a_lastname VARCHAR(64), PRIMARY KEY (a_id) ); CREATE TABLE b_thingy ( b_id INT, b_name VARCHAR(64), PRIMARY KEY (b_id) ); CREATE TABLE bar ( bar_id INT, bar_name varchar(64), PRIMARY KEY (bar_id) ); CREATE TABLE foo ( foo_id INT, foo_a_id INT REFERENCES a_thingy NULL, foo_b_id INT REFERENCES b_thingy NULL, foo_bar_id INT REFERENCES bar NOT NULL, PRIMARY KEY (foo_id), CHECK((foo_a_id IS NOT NULL AND foo_b_id IS NULL) OR (foo_b_id IS NOT NULL AND foo_a_id IS NULL)) ); CREATE VIEW foo_view AS SELECT *, CASE WHEN foo_a_id IS NOT NULL THEN (SELECT a_lastname || ', ' || a_firstname FROM a_thingy WHERE a_id=foo_a_id ) WHEN foo_b_id IS NOT NULL THEN (SELECT b_name FROM b_thingy WHERE b_id=foo_b_id ) END AS thingy_name FROM foo; INSERT INTO a_thingy VALUES (1, 'John', 'Doe'); INSERT INTO b_thingy VALUES (1, 'Megacorp'); INSERT INTO bar VALUES(1, 'squid'); INSERT INTO bar VALUES(2, 'octopus'); INSERT INTO foo VALUES (1,1,NULL,1); INSERT INTO foo VALUES (2,NULL,1,2); -- END ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Shrinkwrap Windows Product, any issues? Anyone? (postmaster
Justin Clift wrote: Hi Igor, This would be a really good thing to get into GBorg as a project, so people could work on this through CVS. Would you like to register it as a project? Mark, do you feel it would be better to put your installer plus this together into one project on GBorg too? Not sure, it's just a thought. I just want to say, the Windows installer was pretty easy once you decide that you are not going to give the user who installs the system the infinite range of options that they would have if they installed cygwin and went from there. We decided on a good middle of the road installation that would work for advanced users. If they want an enterprise server, they will have to modify the installation themselves. I have developed Windows programs since version 1,x, what I see as one of the bigger hurdles in providing UNIX products on Windows is that the UNIX philosophy is that of Capability not Policy. Windows demands a Policy, i.e. when the install is done, they should be able to press start and use it. To do that with postgresql, you have to create an install that will work for most of the people that will want to use it, out of the box, with no fuss. I know I am pontificating, but I do think there is a HUGE market for PostgreSQL on Windows, we just have to figure out how to get it. What I want, is an install that application developers can use as the basis for their ODBC or SQL based projects, instead of MSSQL. Sort of like a Developers version of PostgreSQL. Once we do that, the we have the hook for more reliable and powerful systems. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Quick Help
It works very similarly to the way that ALTER TABLE ... ADD CHECK .. works, with the tuple update added in. Anyway, it's something like the below: - Lock relation - Pull out tuple - Evaluate cooked default expression using EvalExpr - heap_modifytuple (shove datum that EvalExpr returns into column) - simple_heapupdate - Goto step 2 (pull out next tuple) On Thu, 2002-12-05 at 16:24, Christopher Kings-Lynne wrote: Hi guys, Messing about with ADD COLUMN... I'm not certain how to re-evaluate the default expression for each row? How do I do this? I have access to raw_default and cooked_default it seems. Thanks, Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Shrinkwrap Windows Product, any issues? Anyone? (postmaster
mlw wrote: snip Once we do that, the we have the hook for more reliable and powerful systems. Yep, I pretty much agree. :-) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Wishlist for 7.4: Plan stability
Tom Lane [EMAIL PROTECTED] writes: Greg Stark [EMAIL PROTECTED] writes: Really it boils down to one point: there's really no reason to assume a user should be able to execute any new query he feels like. Creating a new query should be privileged operation just like creating a new table or new database. This is an interesting view of what a database should be like, but it has very little to do with my idea of a database ;-). I think you want some sort of middleware layer to keep your users away from the database. This is how people attempt to tackle this problem with Oracle or other databases, but it's an assbackwards design. It leads to a lot of pain and awkwardness and only partially solves the problems. A good design would be elegant and result in a much more manageable system. What I'm really asking for is lower level control of when the query parser and the optimizer runs. That would allow an admin or middleware to control when new queries are parsed and optimized. It could also allow an admin to peek at the existing queries and see what plans are currently in the system, rather than run explain himself and say well this is what it would do if i ran it now, which might be the same thing that ran earlier and caused this performance problem but there's no way to know for sure I do not agree that the DB itself ought to contain such draconian restrictions. Note that the restriction I'm proposing be available is of the form stop the system from doing something for me. This is the kind of feature that's impossible to graft on cleanly in a higher layer. -- greg ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] big text field - message type 0x44
--On Thursday, December 05, 2002 14:02:04 -0500 Tom Lane [EMAIL PROTECTED] wrote: Lee Kindness [EMAIL PROTECTED] writes: Tom Lane writes: Okay, so it seems -D_REENTRANT is the appropriate fix. However, _REENTRANT is not a Solarisism... On all (recent) UNIX systems it toggles on correct handling for thread specific instances of historically global variables (eg errno). It should be considered for all platforms if libpq is intended to be used from threaded programs. Now that I think about it, what that macro is probably really doing is switching the code from looking at a static errno variable to looking at a per-thread variable. So in fact -D_REENTRANT would be correct if you intended to link with a thread-aware libc, and wrong if you intended to link with a non-aware libc. (Is there such a thing as a non-threaded implementation of libc on the platforms where -D_REENTRANT does anything?) If this analysis is right then I think we should *not* force _REENTRANT; it will have to be up to users to choose the mechanism they want to use in their programs. YES. I believe UnixWare7 has such. You need -Kthread to get a threaded version of SOME calls. If you need more details, Ask. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] big text field - message type 0x44
Tom Lane wrote: Lee Kindness [EMAIL PROTECTED] writes: Tom Lane writes: Okay, so it seems -D_REENTRANT is the appropriate fix. However, _REENTRANT is not a Solarisism... On all (recent) UNIX systems it toggles on correct handling for thread specific instances of historically global variables (eg errno). It should be considered for all platforms if libpq is intended to be used from threaded programs. Now that I think about it, what that macro is probably really doing is switching the code from looking at a static errno variable to looking at a per-thread variable. So in fact -D_REENTRANT would be correct if you intended to link with a thread-aware libc, and wrong if you intended to link with a non-aware libc. (Is there such a thing as a non-threaded implementation of libc on the platforms where -D_REENTRANT does anything?) If this analysis is right then I think we should *not* force _REENTRANT; it will have to be up to users to choose the mechanism they want to use in their programs. As far as I remember, on some platforms -lpthread does replace some of the libc functions with thread-safe ones. That could be quite confusing. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
At 12:12 AM 5/12/2002 -0500, Robert Treat wrote: What are the consequences of the problem? One consequence that probably hits home for everyone here is it makes it extremely hard to make a living working with postgresql. ... You can't win marketshare on technology alone I am happy with increasing market share so long a development is not distorted or current users inconvenienced. We have seen the latter with the misplaced announcements. And the former because I am writing this on -hackers, rather than implementing dependency-tracking in pg_dump ;-). ...lots of stuff deleted... Marketing is very relevant to existing customers. Good point. Market Share - Influence -Corprate Support - more features - market share. Gaining market share *is* a natural consequence of improving the product; marketing is about convincing people a product has improved, even if it hasn't. Advocacy is about telling people about the product as it is - and I have no problem with that, with the above proviso. Aren't most development efforts made simply to gain market share? diatribe I seriously hope not - in fact I would find that very depressing. In my opinion, anyone who devotes their personal free time to an open source development project probably has a slew of complex motivations that have little to do with market share. Perhaps the closest they would come would be to say I want to make it better, and in some peoples minds, better is measured by market share. In my case, development I did on other open source projects (libgd) was driven by a philosophical objection to application of patents to software in the US, and to a need for particular features (gd2 format, gif support). My work on PG is driven by a desire to make the product more useful (to me), more usable (for me), and by a philosophical belief in the importance of free open software. The fact that other people ( I) profit from this work is great. In any case, market share, for me, is at best a third order influence - and I assume that's true for most people who contribute to OS software. Although I do admit that there is a natural tendency to want your team to win. /diatribe After all, I don't think we added schema support to get *less* people to use postgresql. I am not sure why it was added, and it's sufficiently esoteric and large that I doubt market share was an issue. If we wanted market share, then online-vacuum and online-upgrade would have been the big-hitters. My guess is that it was done because we did not support it, it is in the SQL standard, and it solved a number of issues that caused existing users developers problems. It was probably also an interesting project. Maybe I'm wrong... Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
On Thu, 05 Dec 2002 21:26:13 -0500, Philip Warner wrote: At 12:12 AM 5/12/2002 -0500, Robert Treat wrote: I am happy with increasing market share so long a development is not distorted or current users inconvenienced. We have seen the latter with the misplaced announcements. It seems to me that people were inconvenienced solely because Mark forgot to CC the right groups and he didn't put the word 7.3 in the right place in his subject line. Oh, and guess it was disruptive for people who killfile any piece of email that has quoted text in it... And the former because I am writing this on -hackers, rather than implementing dependency-tracking in pg_dump ;-). so get back to coding already... ...lots of stuff deleted... Marketing is very relevant to existing customers. Good point. Market Share - Influence -Corprate Support - more features - market share. Gaining market share *is* a natural consequence of improving the product; really? postgresql has been improving by leaps and bounds of the last few years, but I guarantee you it's been losing market share, and it's losing that market share to databases without half the features. marketing is about convincing people a product has improved, even if it hasn't. Advocacy is about telling people about the product as it is - and I have no problem with that, with the above proviso. snip lots more stuff that basically says marketing isn't all bad, it's irrelevant too well, i think any more discussion at this point becomes a semantical argument or a flame war, and I've time for neither. Robert Treat ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] configure error on cvs tip
I just sync'd up with cvs and tried to make clean then configure, and I'm getting this: config.status: linking ./src/backend/libpq/v6util.c to src/interfaces/libpq/v6util.c config.status: error: ./src/backend/libpq/v6util.c: file not found Is this a missing file from the ipv6 stuff that just got committed? Thanks, Joe ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Shrinkwrap Windows Product, any issues? Anyone? (postmaster
Justin: Are you involved with gborg? I have been thinking about Igor's console and my installer. I think there is a good enough need to host a project that contains HOWTOs, scripts, and tools to make PostgreSQL easy for Windows deployment. I am working on a HOWTO, a set of Windows batch files, and the install scripts I would be glad to post, and I would be very glad to include Igor's console in the install. It would make a cool offering. Justin Clift wrote: mlw wrote: snip Once we do that, the we have the hook for more reliable and powerful systems. Yep, I pretty much agree. :-) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Shrinkwrap Windows Product, any issues? Anyone? (postmaster
Hi Mark, mlw wrote: Justin: Are you involved with gborg? Nope, that's Chris Ryan's area. :) I have been thinking about Igor's console and my installer. I think there is a good enough need to host a project that contains HOWTOs, scripts, and tools to make PostgreSQL easy for Windows deployment. It is good to keep all of the instructions+code together, or better to put the instructions somewhere (i.e. the Techdocs site) plus links to the Gborg project to get the code. Either way could work, etc. I am working on a HOWTO, a set of Windows batch files, and the install scripts I would be glad to post, and I would be very glad to include Igor's console in the install. Yep, he does seem to have created a pretty nifty console. It would make a cool offering. :-) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
Bruce Momjian [EMAIL PROTECTED] writes: Peter Eisentraut wrote: Marc G. Fournier writes: It isn't, but those working on -advocacy were asked to help come up with a stronger release *announcement* then we've had in the past ... Consider that a failed experiment. PostgreSQL is driven by the development group and, to some extent, by the existing user base. The last thing we need is a marketing department in that mix. Peter, I understand your perspective, but I think you are in the minority on this one. I tend to agree with Peter. Not that we don't need a marketing presence; we do (I think Great Bridge's marketing efforts are sorely missed). But the point he is making is that the pgsql mailing lists go to people who are generally unimpressed by marketing fluff. And they're already sold on PG anyway. The right way to handle this next time is to generate a PR-style press release to send to outside contacts, but to do our more traditional, technically-oriented announcement on the mailing lists. 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
Re: [HACKERS] PQnotifies() in 7.3 broken?
Lee Kindness wrote: Bruce Momjian writes: Tom Lane wrote: Lee Kindness [EMAIL PROTECTED] writes: Perhaps the .so name should have been updated for PostgreSQL 7.3? It should have been. If it wasn't, that was a serious oversight. Not sure if we should change it in 7.3.1 or not, though; it may be too late for that. Any thoughts out there? Seems I did forget. I always update the minor for a major release, but when development starts, and I seem to have forgotten for 7.3. Sorry. Personally I think automatically updating the version numbers is as bad as not doing it at all - it misses the point. The version numbers in shared library filenames denote binary compatibilty, if the /public/ API changes then the version number really must be incremented. If the version increments without any associated API changes then it's just a PITA for developers and products linking to the PostgreSQL libraries! It forces recompilation when there is not really a need. It is my understanding that only the major number force recompliation. We came up with this procedure after quite a bit of discussion. I am happy to change it, but I need more than one person to tell me that. -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PQnotifies() in 7.3 broken?
Bruce Momjian wrote: I will update for 7.4 now. Too late for 7.3 clearly. Bruce, why is it too late? Most (all) will upgrade to 7.3.1 anyway, so it is a chance to get things right. -- Fernando Nasser Red Hat - Toronto E-Mail: [EMAIL PROTECTED] 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PQnotifies() in 7.3 broken?
Fernando Nasser wrote: Bruce Momjian wrote: I will update for 7.4 now. Too late for 7.3 clearly. Bruce, why is it too late? Most (all) will upgrade to 7.3.1 anyway, so it is a chance to get things right. Oh. yes. Is it safe to do that? -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PQnotifies() in 7.3 broken?
Bruce Momjian [EMAIL PROTECTED] writes: Fernando Nasser wrote: Bruce Momjian wrote: Bruce, why is it too late? Most (all) will upgrade to 7.3.1 anyway, so it is a chance to get things right. Oh. yes. Is it safe to do that? The RPM packagers should probably have a say in this, but I'm leaning to agree with Fernando. The bulk of our users probably will not update from 7.2.* to 7.3 before 7.3.1 is out (at least not for production), so the fact that 7.3 has the wrong library version number won't affect them. But people will continue to get burnt if we don't fix it for 7.3.1. It is not real clear to me whether we need a major version bump, rather than a minor one. We *do* need to signal binary incompatibility. Who can clarify the rules here? 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: [HACKERS] dbmirror
On Thu, 5 Dec 2002, Bruce Momjian wrote:
It looks like the problem was introduced when the SET autocommit
and SET search_path commands were added to the beginning of the script.
The attatched patch should fix the problem. It probably should be applied
against the 7.3 and 7.4 branches.
Yes, I get the same failure. with perl 5.005_03. Steven, can you
comment on this?
---
Tatsuo Ishii wrote:
Hi, I have been playing around with contrib/dbmirror with RC2 and
faced with following errors:
perl DBMirror.pl slaveDatabase.conf
Global symbol $setResult requires explicit package name at DBMirror.pl line 131.
Global symbol $setResult requires explicit package name at DBMirror.pl line 132.
Global symbol $setResult2 requires explicit package name at DBMirror.pl line 140.
Global symbol $setResult2 requires explicit package name at DBMirror.pl line 141.
Execution of DBMirror.pl aborted due to compilation errors.
This Linux and perl 5.6.1.
--
Tatsuo Ishii
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
--
Steven Singer [EMAIL PROTECTED]
Aircraft Performance SystemsPhone: 519-747-1170 ext 282
Navtech Systems Support Inc.AFTN: CYYZXNSX SITA: YYZNSCR
Waterloo, Ontario ARINC: YKFNSCR
*** DBMirror.pl Mon Nov 25 22:31:54 2002
--- DBMirror.pl.cvs Thu Dec 5 20:49:48 2002
***
*** 33,39
#
#
##
! # $Id: DBMirror.pl,v 1.4 2002/11/06 17:50:53 momjian Exp $
#
##
--- 33,39
#
#
##
! # $Id: DBMirror.pl,v 1.3.2.1 2002/11/06 17:51:40 momjian Exp $
#
##
***
*** 128,134
my $setQuery;
$setQuery = SET search_path = public;
! my $setResult = $masterConn-exec($setQuery);
if($setResult-resultStatus!=PGRES_COMMAND_OK) {
logErrorMessage($masterConn-errorMessage . \n .
$setQuery);
--- 128,134
my $setQuery;
$setQuery = SET search_path = public;
! $setResult = $masterConn-exec($setQuery);
if($setResult-resultStatus!=PGRES_COMMAND_OK) {
logErrorMessage($masterConn-errorMessage . \n .
$setQuery);
***
*** 137,143
my $setQuery2;
$setQuery2 = SET autocommit TO 'on';
! my $setResult2 = $masterConn-exec($setQuery2);
if($setResult2-resultStatus!=PGRES_COMMAND_OK) {
logErrorMessage($masterConn-errorMessage . \n .
$setQuery2);
--- 137,143
my $setQuery2;
$setQuery2 = SET autocommit TO 'on';
! $setResult2 = $masterConn-exec($setQuery2);
if($setResult2-resultStatus!=PGRES_COMMAND_OK) {
logErrorMessage($masterConn-errorMessage . \n .
$setQuery2);
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Patch to make Turks happy.
Bruce Momjian wrote:
I am not going to apply this patch because I think it will mess up the
handling of other locales.
As far as I figured from the source code this function only deals with
cleaning up
locale names and nothing else. Since all the locale names are in plain
ASCII I think
it will be safe to use ASCII-only lower-case conversion.
By the way, I noticed only after sending the patch that compiler
complains about
ambiguous `else' so it can be rewritten as:
if (*p = 'A' *p = 'Z'){
*np++ = *p + 'a' - 'A';
}else{
*np++ = *p;
}
Regards,
Nicolai
---
Nicolai Tufar wrote:
Hi,
Yet another problem with Turkish encoding. clean_encoding_name()
in src/backend/utils/mb/encnames.c uses tolower() to convert locale
names to lower-case. This causes errors if locale name contains
capital I and current olcale is Turkish. Some examples:
aaa=# \l
List of databases
Name| Owner | Encoding
---+---+--
aaa | pgsql | LATIN5
bbb | pgsql | LATIN5
template0 | pgsql | LATIN5
template1 | pgsql | LATIN5
(4 rows)
aaa=# CREATE DATABASE ccc ENCODING='LATIN5';
ERROR: LATIN5 is not a valid encoding name
aaa=# \encoding
SQL_ASCII
aaa=# \encoding SQL_ASCII
SQL_ASCII: invalid encoding name or conversion procedure not found
aaa=# \encoding LATIN5
LATIN5: invalid encoding name or conversion procedure not found
Patch, is a simple change to use ASCII-only lower-case conversion
instead of locale-dependent tolower()
Best regards,
Nic.
*** ./src/backend/utils/mb/encnames.c.orig Mon Dec 2 15:58:49 2002
--- ./src/backend/utils/mb/encnames.c Mon Dec 2 18:13:23 2002
***
*** 407,413
for (p = key, np = newkey; *p != '\0'; p++)
{
if (isalnum((unsigned char) *p))
! *np++ = tolower((unsigned char) *p);
}
*np = '\0';
return newkey;
--- 407,416
for (p = key, np = newkey; *p != '\0'; p++)
{
if (isalnum((unsigned char) *p))
! if (*p = 'A' *p = 'Z')
! *np++ = *p + 'a' - 'A';
! else
! *np++ = *p;
}
*np = '\0';
return newkey;
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] dbmirror
Thanks. Applied to 7.3 and CVS HEAD. It was me who added those commands to set the envirnment, and I didn't realize it was the first use of those variables, hence the need for 'my'. Thanks. Fix will be in 7.3.1. --- Steven Singer wrote: On Thu, 5 Dec 2002, Bruce Momjian wrote: It looks like the problem was introduced when the SET autocommit and SET search_path commands were added to the beginning of the script. The attatched patch should fix the problem. It probably should be applied against the 7.3 and 7.4 branches. Yes, I get the same failure. with perl 5.005_03. Steven, can you comment on this? --- Tatsuo Ishii wrote: Hi, I have been playing around with contrib/dbmirror with RC2 and faced with following errors: perl DBMirror.pl slaveDatabase.conf Global symbol $setResult requires explicit package name at DBMirror.pl line 131. Global symbol $setResult requires explicit package name at DBMirror.pl line 132. Global symbol $setResult2 requires explicit package name at DBMirror.pl line 140. Global symbol $setResult2 requires explicit package name at DBMirror.pl line 141. Execution of DBMirror.pl aborted due to compilation errors. This Linux and perl 5.6.1. -- Tatsuo Ishii ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Steven Singer [EMAIL PROTECTED] Aircraft Performance SystemsPhone: 519-747-1170 ext 282 Navtech Systems Support Inc.AFTN: CYYZXNSX SITA: YYZNSCR Waterloo, Ontario ARINC: YKFNSCR Content-Description: [ Attachment, skipping... ] -- 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: [HACKERS] PQnotifies() in 7.3 broken?
Jeroen T. Vermeulen wrote: On Thu, Dec 05, 2002 at 03:27:23PM -0500, Tom Lane wrote: It is not real clear to me whether we need a major version bump, rather than a minor one. We *do* need to signal binary incompatibility. Who can clarify the rules here? One thing I wonder about: should the rules make any distinction between API incompatibilities and client protocol incompatibilities? For the former I would imagine one would like to have some minor version number increase whenever features are added and a major number be incremented when changes become incompatible. For the former, one would probably want to have a similar rule but with a dichotomy between server-side upgrades and client-side upgrades. Yes, now that I remember, that was the big distinction. One requires a recompile, the other one doesn't even work with a newer db. -- 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: [HACKERS] PQnotifies() in 7.3 broken?
Tom Lane writes: It is not real clear to me whether we need a major version bump, rather than a minor one. We *do* need to signal binary incompatibility. Who can clarify the rules here? Strictly speaking, it's platform-dependent, but our shared library code plays a bit of abuse with it. What it comes down to is: If you change or remove an interface, increment the major version number. If you add an interface, increment the minor version number. If you did neither but changed the source code at all, increment the third version number, if we had one. To be thoroughly amused, read the libtool source. Grep for 'version_type'. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [PATCHES] [HACKERS] Patch to make Turks happy.
Bruce Momjian writes:
I am not going to apply this patch because I think it will mess up the
handling of other locales.
This patch looks OK to me. Normally, character set names should use
identifier case-folding rules anyway, so seems to be a step in the right
direction. Much better than saying that users of certain locales can't
properly use PostgreSQL.
---
Nicolai Tufar wrote:
Hi,
Yet another problem with Turkish encoding. clean_encoding_name()
in src/backend/utils/mb/encnames.c uses tolower() to convert locale
names to lower-case. This causes errors if locale name contains
capital I and current olcale is Turkish. Some examples:
aaa=# \l
List of databases
Name| Owner | Encoding
---+---+--
aaa | pgsql | LATIN5
bbb | pgsql | LATIN5
template0 | pgsql | LATIN5
template1 | pgsql | LATIN5
(4 rows)
aaa=# CREATE DATABASE ccc ENCODING='LATIN5';
ERROR: LATIN5 is not a valid encoding name
aaa=# \encoding
SQL_ASCII
aaa=# \encoding SQL_ASCII
SQL_ASCII: invalid encoding name or conversion procedure not found
aaa=# \encoding LATIN5
LATIN5: invalid encoding name or conversion procedure not found
Patch, is a simple change to use ASCII-only lower-case conversion
instead of locale-dependent tolower()
Best regards,
Nic.
*** ./src/backend/utils/mb/encnames.c.orig Mon Dec 2 15:58:49 2002
--- ./src/backend/utils/mb/encnames.c Mon Dec 2 18:13:23 2002
***
*** 407,413
for (p = key, np = newkey; *p != '\0'; p++)
{
if (isalnum((unsigned char) *p))
! *np++ = tolower((unsigned char) *p);
}
*np = '\0';
return newkey;
--- 407,416
for (p = key, np = newkey; *p != '\0'; p++)
{
if (isalnum((unsigned char) *p))
! if (*p = 'A' *p = 'Z')
! *np++ = *p + 'a' - 'A';
! else
! *np++ = *p;
}
*np = '\0';
return newkey;
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
--
Peter Eisentraut [EMAIL PROTECTED]
---(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: [PATCHES] [HACKERS] Patch to make Turks happy.
OK, Peter, that helps. Thanks. I will apply it.
---
Peter Eisentraut wrote:
Bruce Momjian writes:
I am not going to apply this patch because I think it will mess up the
handling of other locales.
This patch looks OK to me. Normally, character set names should use
identifier case-folding rules anyway, so seems to be a step in the right
direction. Much better than saying that users of certain locales can't
properly use PostgreSQL.
---
Nicolai Tufar wrote:
Hi,
Yet another problem with Turkish encoding. clean_encoding_name()
in src/backend/utils/mb/encnames.c uses tolower() to convert locale
names to lower-case. This causes errors if locale name contains
capital I and current olcale is Turkish. Some examples:
aaa=# \l
List of databases
Name| Owner | Encoding
---+---+--
aaa | pgsql | LATIN5
bbb | pgsql | LATIN5
template0 | pgsql | LATIN5
template1 | pgsql | LATIN5
(4 rows)
aaa=# CREATE DATABASE ccc ENCODING='LATIN5';
ERROR: LATIN5 is not a valid encoding name
aaa=# \encoding
SQL_ASCII
aaa=# \encoding SQL_ASCII
SQL_ASCII: invalid encoding name or conversion procedure not found
aaa=# \encoding LATIN5
LATIN5: invalid encoding name or conversion procedure not found
Patch, is a simple change to use ASCII-only lower-case conversion
instead of locale-dependent tolower()
Best regards,
Nic.
*** ./src/backend/utils/mb/encnames.c.origMon Dec 2 15:58:49 2002
--- ./src/backend/utils/mb/encnames.c Mon Dec 2 18:13:23 2002
***
*** 407,413
for (p = key, np = newkey; *p != '\0'; p++)
{
if (isalnum((unsigned char) *p))
! *np++ = tolower((unsigned char) *p);
}
*np = '\0';
return newkey;
--- 407,416
for (p = key, np = newkey; *p != '\0'; p++)
{
if (isalnum((unsigned char) *p))
! if (*p = 'A' *p = 'Z')
! *np++ = *p + 'a' - 'A';
! else
! *np++ = *p;
}
*np = '\0';
return newkey;
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
--
Peter Eisentraut [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 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [PATCHES] [HACKERS] Patch to make Turks happy.
OK, patch applied. Peter, should this appear in 7.3.1 too?
---
Peter Eisentraut wrote:
Bruce Momjian writes:
I am not going to apply this patch because I think it will mess up the
handling of other locales.
This patch looks OK to me. Normally, character set names should use
identifier case-folding rules anyway, so seems to be a step in the right
direction. Much better than saying that users of certain locales can't
properly use PostgreSQL.
---
Nicolai Tufar wrote:
Hi,
Yet another problem with Turkish encoding. clean_encoding_name()
in src/backend/utils/mb/encnames.c uses tolower() to convert locale
names to lower-case. This causes errors if locale name contains
capital I and current olcale is Turkish. Some examples:
aaa=# \l
List of databases
Name| Owner | Encoding
---+---+--
aaa | pgsql | LATIN5
bbb | pgsql | LATIN5
template0 | pgsql | LATIN5
template1 | pgsql | LATIN5
(4 rows)
aaa=# CREATE DATABASE ccc ENCODING='LATIN5';
ERROR: LATIN5 is not a valid encoding name
aaa=# \encoding
SQL_ASCII
aaa=# \encoding SQL_ASCII
SQL_ASCII: invalid encoding name or conversion procedure not found
aaa=# \encoding LATIN5
LATIN5: invalid encoding name or conversion procedure not found
Patch, is a simple change to use ASCII-only lower-case conversion
instead of locale-dependent tolower()
Best regards,
Nic.
*** ./src/backend/utils/mb/encnames.c.origMon Dec 2 15:58:49 2002
--- ./src/backend/utils/mb/encnames.c Mon Dec 2 18:13:23 2002
***
*** 407,413
for (p = key, np = newkey; *p != '\0'; p++)
{
if (isalnum((unsigned char) *p))
! *np++ = tolower((unsigned char) *p);
}
*np = '\0';
return newkey;
--- 407,416
for (p = key, np = newkey; *p != '\0'; p++)
{
if (isalnum((unsigned char) *p))
! if (*p = 'A' *p = 'Z')
! *np++ = *p + 'a' - 'A';
! else
! *np++ = *p;
}
*np = '\0';
return newkey;
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
--
Peter Eisentraut [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
Index: src/backend/utils/mb/encnames.c
===
RCS file: /cvsroot/pgsql-server/src/backend/utils/mb/encnames.c,v
retrieving revision 1.10
diff -c -c -r1.10 encnames.c
*** src/backend/utils/mb/encnames.c 4 Sep 2002 20:31:31 - 1.10
--- src/backend/utils/mb/encnames.c 5 Dec 2002 23:19:40 -
***
*** 407,413
for (p = key, np = newkey; *p != '\0'; p++)
{
if (isalnum((unsigned char) *p))
! *np++ = tolower((unsigned char) *p);
}
*np = '\0';
return newkey;
--- 407,418
for (p = key, np = newkey; *p != '\0'; p++)
{
if (isalnum((unsigned char) *p))
! {
! if (*p = 'A' *p = 'Z')
! *np++ = *p + 'a' - 'A';
! else
! *np++ = *p;
! }
}
*np = '\0';
return newkey;
---(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: [HACKERS] [GENERAL] PostgreSQL Global Development Group
Folks, We have a marketing group: PGSQL-ADVOCACY. Our problem is that we don't have enough volunteers. For example, last week Robert and Justin had job crises, and I left for the mountains for Thanksgiving. As a result Marc had to pitch in at the last minute to try to get some kind of release out. Thus the lack of coordinated media splash for the 7.3 release. We need more people!!! We have right now about 7 active volunteers and 6-8 translators for Advocacy. That's not nearly enough. If the people on this thread care about marketing Postgresql, then please join the pgsql-advocacy mailing list. BTW, we do coordinate with the Website development group, and for that matter TechDocs. -Josh Berkus ---(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: [HACKERS] configure error on cvs tip
Fixing now. This just isn't my night --- another patch with a missing file. --- Joe Conway wrote: I just sync'd up with cvs and tried to make clean then configure, and I'm getting this: config.status: linking ./src/backend/libpq/v6util.c to src/interfaces/libpq/v6util.c config.status: error: ./src/backend/libpq/v6util.c: file not found Is this a missing file from the ipv6 stuff that just got committed? Thanks, Joe ---(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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] configure error on cvs tip
Bruce Momjian wrote: Fixing now. This just isn't my night --- another patch with a missing file. OK - I can run configure and make now, but I'm getting these warnings: In file included from ../../../../src/include/libpq/libpq.h:22, from printtup.c:20: ../../../../src/include/libpq/v6util.h:3: warning: `struct addrinfo' declared inside parameter list ../../../../src/include/libpq/v6util.h:3: warning: its scope is only this definition or declaration, which is probably not what you want. ../../../../src/include/libpq/v6util.h:5: warning: `struct addrinfo' declared inside parameter list lots of similar warnings to the above -- and: auth.c: In function `ClientAuthentication': auth.c:414: warning: passing arg 1 of `isAF_INETx' from incompatible pointer type gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -c -o crypt.o crypt.c -MMD In file included from ../../../src/include/libpq/libpq.h:22, from crypt.c:24: Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] configure error on cvs tip
Yep, I am about to yank out the whole patch. I am seeing on postmaster startup: LOG: FATAL: StreamServerPort: getaddrinfo2() failed: hostname nor servname provided, or not known What is strange is that initdb worked. I will just throw it back to the author. Done. Code is returned to author for review. --- Joe Conway wrote: Bruce Momjian wrote: Fixing now. This just isn't my night --- another patch with a missing file. OK - I can run configure and make now, but I'm getting these warnings: In file included from ../../../../src/include/libpq/libpq.h:22, from printtup.c:20: ../../../../src/include/libpq/v6util.h:3: warning: `struct addrinfo' declared inside parameter list ../../../../src/include/libpq/v6util.h:3: warning: its scope is only this definition or declaration, which is probably not what you want. ../../../../src/include/libpq/v6util.h:5: warning: `struct addrinfo' declared inside parameter list lots of similar warnings to the above -- and: auth.c: In function `ClientAuthentication': auth.c:414: warning: passing arg 1 of `isAF_INETx' from incompatible pointer type gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -c -o crypt.o crypt.c -MMD In file included from ../../../src/include/libpq/libpq.h:22, from crypt.c:24: Joe -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] configure error on cvs tip
Bruce Momjian wrote: Yep, I am about to yank out the whole patch. I am seeing on postmaster startup: LOG: FATAL: StreamServerPort: getaddrinfo2() failed: hostname nor servname provided, or not known What is strange is that initdb worked. I will just throw it back to the author. Done. Code is returned to author for review. hmmm -- now I'm back to : config.status: linking ./src/backend/libpq/v6util.c to src/interfaces/libpq/v6util.c config.status: error: ./src/backend/libpq/v6util.c: file not found Joe ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] configure error on cvs tip
BJoe Conway wrote: Bruce Momjian wrote: Yep, I am about to yank out the whole patch. I am seeing on postmaster startup: LOG: FATAL: StreamServerPort: getaddrinfo2() failed: hostname nor servname provided, or not known What is strange is that initdb worked. I will just throw it back to the author. Done. Code is returned to author for review. hmmm -- now I'm back to : config.status: linking ./src/backend/libpq/v6util.c to src/interfaces/libpq/v6util.c config.status: error: ./src/backend/libpq/v6util.c: file not found Sorry. Run autoconf. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] configure error on cvs tip
Bruce Momjian wrote: Sorry. Run autoconf. OK -- works now. I've never needed to do that before. Thanks! Joe ---(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
[HACKERS] IPv6 patch rejected
The INETv6 patch was rejected because of this report, and an error on postmaster startup from BSD/OS: LOG: FATAL: StreamServerPort: getaddrinfo2() failed: hostname nor servname provided, or not known Please submit a new patch that addresses these issues. I can work with you to do testing. --- Joe Conway wrote: Bruce Momjian wrote: Fixing now. This just isn't my night --- another patch with a missing file. OK - I can run configure and make now, but I'm getting these warnings: In file included from ../../../../src/include/libpq/libpq.h:22, from printtup.c:20: ../../../../src/include/libpq/v6util.h:3: warning: `struct addrinfo' declared inside parameter list ../../../../src/include/libpq/v6util.h:3: warning: its scope is only this definition or declaration, which is probably not what you want. ../../../../src/include/libpq/v6util.h:5: warning: `struct addrinfo' declared inside parameter list lots of similar warnings to the above -- and: auth.c: In function `ClientAuthentication': auth.c:414: warning: passing arg 1 of `isAF_INETx' from incompatible pointer type gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -c -o crypt.o crypt.c -MMD In file included from ../../../src/include/libpq/libpq.h:22, from crypt.c:24: Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Please, apply patch of tsearch for current CVS 7.3.1
Patch applied to HEAD and 7.3. Thanks. --- Teodor Sigaev wrote: Thank you very much, you catch it :). This bug had a long life, because it exists if and only if locale of postmaster was a different from C (or ru_RU.KOI8-R). Please, apply patch for current CVS 7.3.1 Magnus Naeslund(f) wrote: Ok, I nailed the bug, but i'm not sure what the correct fix is. Attached tsearch_morph.diff that remedies this problem by avoiding it. Also there's a debug aid patch if someone would like to know how i finally found it out :) There problem in the lemmatize() function is that GETDICT(...) returned a value not handled (BYLOCALE). The value (-1) and later used as an index into the dicts[] array. After that everything went berserk stack went crazy somehow so trapping the fault sent me to the wrong place, and every time i read the value it was positive ;) So now i just return the initial word passed to the lemmatize function, because i don't know what to do with it. So you tsearch guys will have to work it out :) -- Teodor Sigaev [EMAIL PROTECTED] [ application/gzip is not supported, skipping... ] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [ADMIN] how to alter sequence.
I don't think you can drop/recreate the sequence because the dependency code knows other tables depend on it. --- Rajesh Kumar Mallah. wrote: Doesn't dropping and recreating the sequence suit the bill ? whats' the major advantage to implement em as a command? At least one thing from which all of us can benifit in PgSQL is replication. I just hope 7.4 give us some sort of master/slave replication. Regds Mallah. On Wednesday 04 December 2002 11:53 pm, Bruce Momjian wrote: Oliver Elphick wrote: On Wed, 2002-12-04 at 12:29, raja kumar thatte wrote: Hai friends, I have a sequence called raj_seq with max value 3000. ... now i wanted to increase the max value of the raj_seq to 999. How to do this change? If i drop and recreate the raj_seq, then i have to recreate the table and all triggers working on that table.But it is not an acceptable solution. So with out droping raj_seq , how do I solve this problem. Unfortunately there doesn't seem to be any easy way to do this. There is no ALTER SEQUENCE command and you can't use UPDATE on a sequence. Gee, I thought they could just update the sequence table, but I see: test= update yy set max_value = 100; ERROR: You can't change sequence relation yy Hackers: Could this be a TODO item for 7.4? Added to TODO: * Add ALTER SEQUENCE to modify min/max/increment/cache/cycle values -- Rajesh Kumar Mallah, Project Manager (Development) Infocom Network Limited, New Delhi phone: +91(11)6152172 (221) (L) ,9811255597 (M) Visit http://www.trade-india.com , India's Leading B2B eMarketplace. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- 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 4: Don't 'kill -9' the postmaster
[HACKERS] 7.3-2 RPMset released.
Due to a late-night typo, the 7.3-1 RPMset released last night would start the postmaster for the first time, but not subsequent times. I have corrected the problem and uploaded a 7.3-2 RPMset. If you do not want to download the whole set again to fix a single-character bug, edit the file /etc/rc.d/init.d/postgresql, and find the line that says: if [ `cat $PGDATA/PG_VERSION` != '7.2' ] Change the 7.2 to 7.3. (ARGH!) My aopologies for the inconvenience -- I installed the 7.3-1 RPMset and ran the regression tests on it last night (all but one test passed -- the one that failed was due to the collation of a result, and a side-effect of the way the RPM regression testing is performed); but I did not try a restart of the postmaster. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
