[HACKERS] use of IDE's an tools

2004-11-05 Thread Gevik Babakhani
Dear people, Would you please be so kind to help me with some pointers about which IDEs you use in order to compile and take a look at the sources? Any comment is appreciated. Regards, Gevik.

Re: [HACKERS] CVS should die (was: Possible make_oidjoins_check ...)

2004-11-05 Thread David Helgason
The intuitive understanding of a file is certainly something like a file called 'baz.c' residing at 'foo/bar/', which contains the BAZ subsystem. Now, when renaming/moving a file such an intuitive understanding is partially lost. UI-wise that's a problem which I haven't ever seen solved well.

[HACKERS] unnest

2004-11-05 Thread John Hansen
Attached, array - rows iterator. select * from unnest(array[1,2,3,4,5]); Unnest --- 1 2 3 4 5 5 rows The switch statement could probably be done in a different way, but there doesn't seem to be any good examples of how to return anyitem. If anyone have a better way, please let

Re: [HACKERS] [pgsql-www] pg_autovacuum is nice ... but ...

2004-11-05 Thread Gaetano Mendola
Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: Moved to -hackers where this belongs :) On Fri, 5 Nov 2004, Justin Clift wrote: Would making max_fsm_relations and max_fsm_pages dynamically update themselves whilst PostgreSQL runs be useful? Possibly, but it isn't happening in

Re: [HACKERS] CVS should die

2004-11-05 Thread Thomas Hallgren
Joerg Hessdoerfer wrote: Advocacy Yes, some do. At least SVN (Subversion) can handle moves very well, and especially it doesn't loose history on moves/renames. SVN holds it's repo entries in a database like 'filesystem', which can be backed by BDB4 or flat files (as of 1.1). SVN has proven to be

Re: [HACKERS] [pgsql-www] pg_autovacuum is nice ... but ...

2004-11-05 Thread Neil Conway
Gaetano Mendola wrote: Right but we can create a new segment and use it too. I don't know how these segments are used but I used to do it in the past, of course you have to create a memory manager that handle not ccntinuous segments. The TelegraphCQ folks have already done this:

Re: [HACKERS] [PATCHES] CVS should die

2004-11-05 Thread Neil Conway
Thomas Hallgren wrote: Another compelling reason to use SVN is that one of their long term goals is to use an SQL backend. That is about as far from a compelling reason to use a particular version control system as I can imagine. -Neil ---(end of

Re: [HACKERS] [pgsql-www] pg_autovacuum is nice ... but ...

2004-11-05 Thread Gaetano Mendola
Neil Conway wrote: Gaetano Mendola wrote: Right but we can create a new segment and use it too. I don't know how these segments are used but I used to do it in the past, of course you have to create a memory manager that handle not ccntinuous segments. The TelegraphCQ folks have already

Re: [HACKERS] [PATCHES] CVS should die

2004-11-05 Thread Andrew Dunstan
Neil Conway wrote: Thomas Hallgren wrote: Another compelling reason to use SVN is that one of their long term goals is to use an SQL backend. That is about as far from a compelling reason to use a particular version control system as I can imagine. Yeah. I see these considerations as being

Re: [HACKERS] [PATCHES] CVS should die

2004-11-05 Thread Thomas Hallgren
Andrew Dunstan wrote: Neil Conway wrote: Thomas Hallgren wrote: Another compelling reason to use SVN is that one of their long term goals is to use an SQL backend. That is about as far from a compelling reason to use a particular version control system as I can imagine. Yeah. I see these

Re: [HACKERS] [PATCHES] CVS should die

2004-11-05 Thread Peter Eisentraut
Am Freitag, 5. November 2004 14:13 schrieb Andrew Dunstan: I'll repeat an observation I made (more or less) last time we had this discussion: the loudest voice in it belongs to those who actually use the repository most. When Tom or Bruce or Peter (for example) tell us we need to change I'll

[HACKERS] Documentation on PITR still scarce

2004-11-05 Thread Joachim Wieland
Hi there, I just wanted to try the PITR feature in beta and got it working somehow. However I think the docs on this point are still not sufficient enough. We have to assume that people will have a closer look at the backup/recovery documentation as soon as 8.0 ships, because we're kinda heavily

Re: [HACKERS] [PATCHES] CVS should die

2004-11-05 Thread Andrew Dunstan
Peter Eisentraut wrote: I think for a start it would be nice if pgfoundry could optionally offer subversion (and/or arch) for source control, so that some developer groups and also our system administrators could get some experience with it. I agree. We (the pgfoundry admins) will see what

Re: [HACKERS] [PATCHES] CVS should die

2004-11-05 Thread Gaetano Mendola
Peter Eisentraut wrote: Am Freitag, 5. November 2004 14:13 schrieb Andrew Dunstan: I'll repeat an observation I made (more or less) last time we had this discussion: the loudest voice in it belongs to those who actually use the repository most. When Tom or Bruce or Peter (for example) tell us we

Re: [HACKERS] [pgsql-hackers] fsm_ variables ...

2004-11-05 Thread Josh Berkus
Marc, Just thought of something after reading and deleting Gavin's email ... don't we have a 'pgtune' utility, or wasn't that something someone was working? how many settings, like fsm, can be determined by analzying a database? Well, Justin started writing something (see pg_autotune on

Re: [HACKERS] Documentation on PITR still scarce

2004-11-05 Thread simon
Joachim Wieland [EMAIL PROTECTED] wrote on 05.11.2004, 16:28:38: Hi there, I just wanted to try the PITR feature in beta and got it working somehow. However I think the docs on this point are still not sufficient enough. We have to assume that people will have a closer look at the

Re: [HACKERS] [pgsql-www] pg_autovacuum is nice ... but ...

2004-11-05 Thread Gaetano Mendola
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Treat wrote: | On Friday 05 November 2004 07:48, Gaetano Mendola wrote: | |Neil Conway wrote: | Gaetano Mendola wrote: | Right but we can create a new segment and use it too. I don't know how | these segments are used but I used to do it in

Re: [HACKERS] [PATCHES] CVS should die

2004-11-05 Thread Heikki Linnakangas
On Fri, 5 Nov 2004, Gaetano Mendola wrote: Peter Eisentraut wrote: I'm certainly open to considering subversion, although I have a certain traumatic experience with it that may or may not be related to the BDB backend that it uses. I think for a start it would be nice if pgfoundry could

Re: [HACKERS] [PATCHES] CVS should die

2004-11-05 Thread Joshua D. Drake
Heikki Linnakangas wrote: On Fri, 5 Nov 2004, Gaetano Mendola wrote: Peter Eisentraut wrote: I'm certainly open to considering subversion, although I have a certain traumatic experience with it that may or may not be related to the BDB backend that it uses. I think for a start it would be nice

[HACKERS] Backend 8.0.0B4 crash on SELECT ...

2004-11-05 Thread James Robinson
I can reproduce a 8.0.0B4 backend crash on OSX 1.3.5. I can't even get it to analyze the query to get an idea of what the plan it is trying. What can I do to help diagnose what is going on? Here's the query: SELECT unit.id FROM unit WHERE unit.delete = 'f' AND unit.status=2 AND (

Re: [HACKERS] Documentation on PITR still scarce

2004-11-05 Thread Joachim Wieland
Simon, thanks for that quick and detailed answer. On Fri, Nov 05, 2004 at 05:42:01PM +0100, [EMAIL PROTECTED] wrote: The sample file gives additional information, just as occurs with pg_hba.conf. I don't see any need to replicate the sample file in the docs, do you? Well, maybe one could add

Re: [HACKERS] [PATCHES] CVS should die

2004-11-05 Thread Gaetano Mendola
Heikki Linnakangas wrote: I tried that yesterday out of curiosity. It had problems with 3 files which I removed manually: /pgsql/src/interfaces/perl5/Attic/ApachePg.pl,v /pgsql/src/interfaces/perl5/Attic/test.pl.newstyle,v /pgsql/src/interfaces/perl5/Attic/test.pl.oldstyle.pl,v Otherwise, no

Re: [HACKERS] [PATCHES] CVS should die

2004-11-05 Thread Ian Barwick
On Fri, 5 Nov 2004 16:22:55 +0100, Peter Eisentraut [EMAIL PROTECTED] wrote: Am Freitag, 5. November 2004 14:13 schrieb Andrew Dunstan: I'll repeat an observation I made (more or less) last time we had this discussion: the loudest voice in it belongs to those who actually use the repository

Re: [HACKERS] [PATCHES] CVS should die

2004-11-05 Thread Heikki Linnakangas
On Fri, 5 Nov 2004, Gaetano Mendola wrote: Heikki Linnakangas wrote: FWIW, I think Peter's idea of offering Subversion as an alternative in pgfoundry is very good. Mmm, do you mean createing periodically snapshot? Yes this could be a good idea. No, I mean that each project could choose to use

Re: [HACKERS] Using ALTER TABLESPACE in pg_dump

2004-11-05 Thread Tom Lane
Philip, I've just committed the backend changes involved in setting up a default_tablespace GUC variable for pg_dump to use, but I didn't do anything to convert pg_dump to doing so instead of using explicit TABLESPACE clauses. You had muttered something about wanting to add a TOC entry field

Re: [HACKERS] [PATCHES] CVS should die

2004-11-05 Thread Gaetano Mendola
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Heikki Linnakangas wrote: | Have you looked at TortoiseCVS (www.tortoisecvs.org)? I think | TortoiseSVN is a fork of that. I didn't know the existence, is not even listed in the subproject on CVS home page, I discovered TortoiseSVN on the Subversion

Re: [HACKERS] unnest

2004-11-05 Thread Kris Jurka
On Fri, 5 Nov 2004, John Hansen wrote: Does anyone know how to check individual array elements for NULL values? PG_ARG_ISNULL() seems to return true if ANY array element is null; ex:: array[1,2,3,null,4,5] Arrays cannot store NULL elements, check your above statement and see that the whole

Re: [HACKERS] [PATCHES] CVS should die

2004-11-05 Thread Tom Lane
Ian Barwick [EMAIL PROTECTED] writes: Aha, glad I'm not the only one. Version 1.1 has a flat-file based backend which is not prone to BDB-permission-related problems, see: http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.4 . It's only been around a few months though and the

Re: [HACKERS] [PATCHES] CVS should die

2004-11-05 Thread Heikki Linnakangas
On Fri, 5 Nov 2004, Travis P wrote: Heikki Linnakangas wrote: Interestingly, the subversion repository is 585MB, and the CVS repository is only 260MB, BDB or FSFS back-end? FSFS seems to require less space. (The BDB backend tends to pre-allocate space though, so maybe there was a big jump, but

Re: [HACKERS] Backend 8.0.0B4 crash on SELECT ...

2004-11-05 Thread Tom Lane
James Robinson [EMAIL PROTECTED] writes: I can reproduce a 8.0.0B4 backend crash on OSX 1.3.5. Fixed; thanks for the test case. If you need the patch right away, here it is. regards, tom lane *** src/backend/optimizer/path/indxpath.c.orig Mon Oct 11 18:56:56 2004 ---

Re: [HACKERS] Backend 8.0.0B4 crash on SELECT ...

2004-11-05 Thread James Robinson
Patch applied, fixes beta4 for the query with our data. Many thanks again! James Robinson Socialserve.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Documentation on PITR still scarce

2004-11-05 Thread Simon Riggs
On Fri, 2004-11-05 at 18:10, Joachim Wieland wrote: My first mistake was that I kept the archive_command setting and thus overwrote my original archive files. Maybe you should add a note that one should set it to another directory when recovering. That is exactly the situation Timelines are

Re: [HACKERS] [PATCHES] CVS should die

2004-11-05 Thread Markus Bertheau
, 05.11.2004, 21:40, Heikki Linnakangas : On Fri, 5 Nov 2004, Travis P wrote: Heikki Linnakangas wrote: Interestingly, the subversion repository is 585MB, and the CVS repository is only 260MB, BDB or FSFS back-end? FSFS seems to require less space. (The BDB backend tends to

Re: [HACKERS] Documentation on PITR still scarce

2004-11-05 Thread Joachim Wieland
Hi, On Fri, Nov 05, 2004 at 10:26:55PM +, Simon Riggs wrote: That is exactly the situation Timelines are designed to avoid. This should not have happened. What leads you to think it has? My guess is that it has not. If it has, its a bug. Hmm. I did the following: - I recovered to one

Re: [HACKERS] [PATCHES] CVS should die

2004-11-05 Thread Andrew Dunstan
Markus Bertheau wrote: , 05.11.2004, 21:40, Heikki Linnakangas : On Fri, 5 Nov 2004, Travis P wrote: Heikki Linnakangas wrote: Interestingly, the subversion repository is 585MB, and the CVS repository is only 260MB, BDB or FSFS back-end? FSFS seems to require less

Re: [HACKERS] Using ALTER TABLESPACE in pg_dump

2004-11-05 Thread Philip Warner
At 06:19 AM 6/11/2004, Tom Lane wrote: You had muttered something about wanting to add a TOC entry field for this --- do you still want to do the work? You can probably get it done faster than I could, but I dunno if you have time at the moment. I'd like to get it in over the weekend so that we

Re: [HACKERS] Using ALTER TABLESPACE in pg_dump

2004-11-05 Thread Tom Lane
Philip Warner [EMAIL PROTECTED] writes: Time is at a serious premium for me at the moment (I have several projects all due about now); but I wrote a patch for this a few weeks back, so it should not be a lot of work (unless pg_dump has changed in the last couple of months). If you have a

[HACKERS] Release schedule plans

2004-11-05 Thread Bruce Momjian
In talking to people working on various items, I think we should plan for a beta next week once we have completed all the major open 8.0 items. Only the tablespace and win32 lost signals seem major. And, once the beta has been tested for a week, we should start thinking about an 8.0 release

Re: [HACKERS] Using ALTER TABLESPACE in pg_dump

2004-11-05 Thread Bruce Momjian
TODO item removed: * Allow database recovery where tablespaces can't be created When a pg_dump is restored, all tablespaces will attempt to be created in their original locations. If this fails, the user must be able to adjust the restore process. Not done yet, but it will be with SET

Re: [HACKERS] Using ALTER TABLESPACE in pg_dump

2004-11-05 Thread Bruce Momjian
FYI, we need tablespace_default to control this pg_dump output for a primary key: ALTER TABLE ONLY test2 ADD CONSTRAINT test2_pkey PRIMARY KEY (x); --- Tom Lane wrote: Philip Warner [EMAIL PROTECTED]

Re: [HACKERS] [PATCHES] CVS should die

2004-11-05 Thread Greg Stark
Heikki Linnakangas wrote: Interestingly, the subversion repository is 585MB, and the CVS repository is only 260MB, So apparently this is a limitation of svn2cvs. It uses a lot more space to represent tags and branches than would be required if they had been created in svn directly.

Re: [HACKERS] [PATCHES] CVS should die

2004-11-05 Thread Bruce Momjian
Greg Stark wrote: Heikki Linnakangas wrote: Interestingly, the subversion repository is 585MB, and the CVS repository is only 260MB, So apparently this is a limitation of svn2cvs. It uses a lot more space to represent tags and branches than would be required if they had been created

Re: [HACKERS] [PATCHES] CVS should die

2004-11-05 Thread Andrew Dunstan
Greg Stark said: Andrew Dunstan [EMAIL PROTECTED] writes: This just reinforces Tom's well-made point about maturity/stability. I rejected using SVN on another project a few months ago for just this sort of reason. I'm not sure what this says about maturity, you realize read-only access