Re: [HACKERS] ERROR action extension for rules?
CREATE RULE PasTouche AS ON UPDATE TO foo WHERE old.locked=TRUE DO INSTEAD ERROR; This would be sensible if rules were actually reasonable substitutes for triggers, but they are not. If you check the archives you will find many many cases where people tried to do this sort of thing, and got burned by the fundamental semantic differences ... Ok, I'll look into that. Thanks for the pointer. -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_autovacuum crashes when query fails for temp tables
On Wednesday 21 April 2004 12:05 am, Christopher Kings-Lynne wrote: No, I have not heard of a 7.4.3 timeline, but we certainly want your eventual fixes in that release. Right, and along these lines there are a few other pg_autovacuum bugs that were fixed just after 7.4.2. A rollable log solution would be nice :) Syslog? :) Agreed, but I don't see that being added into the 7.4 release, I think the patch would be bounced if I tried it. For 7.5 pg_autovacumm will be integrated in to the backend allowing the use of the logging functions already available there. Matthew ---(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] Pl/Java and GCJ
Hi, I've made some very encouraging tests using The GNU version of Java known as GCJ together with my Pl/Java implementation . At present I use GCJ just like any other JVM, i.e. as an interpreter. This is not very optimal since GCJ can compile all Java code into shared libraries just like it would compile C or C++ code. Putting it short, there's a tradeoff between adhering to the proposed standard for SQL/Java mapping and using precompiled shared objects. Pre-loaded modules loaded by the postmaster for instance, can never be standard although it will help boost performance a great deal. I guess that extending the proposed functionality is OK as long as attempts are made to follow the standard whenever possible. To do this, I'd like some advice concerning loading of shared libraries that are the result of a jar file gcj compilation. Today, using a normal JVM, I can install modules in the form of jar files into the database. The modules can then be used dynamically and on demand by Pl/Java. Using GCJ, I'd like to have the same semantics from a user perspective (since they are modelled from the standard proposal) but behind the scene the jar file should be compiled into a shared library which then is made available to postgres. Question is, where do I store the shared object, and how do I load it? Ideally, I'd like it to be stored in the database and subject to normal grant/revoke rights etc. but dlopen() will hardly look there. So instead, I'd like to store it somewhere in the filesystem on the server where postmaster runs. Is PostgreSQL doing something similar in other places today (i.e. install a shared library on the server using SQL commands issued from the client)? Any thoughts and/or ideas on this are greatly appreciated. More on Pl/Java here: http://gborg.postgresql.org/project/pljava Kind Regards, Thomas Hallgren ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] contrib vs. gborg/pgfoundry for replication solutions
Taking into account that quite a few people have repeatedly stated that the components in contrib are considered more supported/recommended than similar solutions found on gborg or any other external site, I suggest we move the projects dbmirror and dblink to gborg. The rserv contrib module seems to me to be an early Perl prototype of erserver, nobody is working on any more. I suggest we drop that entirely. Comments/alternatives? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(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] contrib vs. gborg/pgfoundry for replication solutions
Hello, My personal opinion is that contrib should be removed entirely. Just have a contrib.txt that says all contrib modules are at pgfoundry or whatever. Sincerely, Joshua D. Drake Jan Wieck wrote: Taking into account that quite a few people have repeatedly stated that the components in contrib are considered more supported/recommended than similar solutions found on gborg or any other external site, I suggest we move the projects dbmirror and dblink to gborg. The rserv contrib module seems to me to be an early Perl prototype of erserver, nobody is working on any more. I suggest we drop that entirely. Comments/alternatives? Jan ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
Jan Wieck wrote: Taking into account that quite a few people have repeatedly stated that the components in contrib are considered more supported/recommended than similar solutions found on gborg or any other external site, I suggest we move the projects dbmirror and dblink to gborg. The rserv contrib module seems to me to be an early Perl prototype of erserver, nobody is working on any more. I suggest we drop that entirely. Comments/alternatives? Agreed. -- 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] valgrind errors
Valgrind'ing the postmaster yields a fair number of errors. A lot of them are similar, such as the following: ==29929== Use of uninitialised value of size 4 ==29929==at 0x80AFB80: XLogInsert (xlog.c:570) ==29929==by 0x808B0A6: heap_insert (heapam.c:1189) ==29929==by 0x808B19D: simple_heap_insert (heapam.c:1226) ==29929==by 0x80C28CC: AddNewAttributeTuples (heap.c:499) ==29929==by 0x80C2E36: heap_create_with_catalog (heap.c:787) ==29929==by 0x811F5AD: DefineRelation (tablecmds.c:252) ==29929==by 0x81DC9BF: ProcessUtility (utility.c:376) ==29929==by 0x81DB893: PortalRunUtility (pquery.c:780) ==29929==by 0x81DB9CE: PortalRunMulti (pquery.c:844) ==29929==by 0x81DB35C: PortalRun (pquery.c:501) ==29929==by 0x81D75E2: exec_simple_query (postgres.c:935) ==29929==by 0x81D9F95: PostgresMain (postgres.c:2984) ==29929== ==29929== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==29929==at 0x3C1BAB28: write (in /usr/lib/debug/libc-2.3.2.so) ==29929==by 0x80B2124: XLogFlush (xlog.c:1416) ==29929==by 0x80AE348: RecordTransactionCommit (xact.c:549) ==29929==by 0x80AE82A: CommitTransaction (xact.c:930) ==29929==by 0x80AED8B: CommitTransactionCommand (xact.c:1242) ==29929==by 0x81D8934: finish_xact_command (postgres.c:1820) ==29929==by 0x81D762C: exec_simple_query (postgres.c:967) ==29929==by 0x81D9F95: PostgresMain (postgres.c:2984) ==29929==by 0x81A524E: BackendRun (postmaster.c:2662) ==29929==by 0x81A489E: BackendStartup (postmaster.c:2295) ==29929==by 0x81A2D0A: ServerLoop (postmaster.c:1165) ==29929==by 0x81A2773: PostmasterMain (postmaster.c:926) ==29929== Address 0x3C37BB57 is not stack'd, malloc'd or free'd (These occur hundreds of times while valgrind'ing make installcheck.) The particular call chain that results in the XLogInsert() error is variable; for example, here's another error report: ==29937== Use of uninitialised value of size 4 ==29937==at 0x80AFA37: XLogInsert (xlog.c:555) ==29937==by 0x80978F3: _bt_split (nbtinsert.c:907) ==29937==by 0x80966A1: _bt_insertonpg (nbtinsert.c:504) ==29937==by 0x8095BB0: _bt_doinsert (nbtinsert.c:141) ==29937==by 0x809CC78: btinsert (nbtree.c:266) ==29937==by 0x826200E: OidFunctionCall6 (fmgr.c:1484) ==29937==by 0x80944FA: index_insert (indexam.c:226) ==29937==by 0x80C79E6: CatalogIndexInsert (indexing.c:121) ==29937==by 0x80C2A0B: AddNewAttributeTuples (heap.c:557) ==29937==by 0x80C2E36: heap_create_with_catalog (heap.c:787) ==29937==by 0x811F5AD: DefineRelation (tablecmds.c:252) ==29937==by 0x81DC9BF: ProcessUtility (utility.c:376) Any thoughts on what could be causing these errors? (I looked into it, but couldn't see anything that looked like an obvious culprit.) -Neil ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
Joshua D. Drake wrote: Hello, My personal opinion is that contrib should be removed entirely. Just have a contrib.txt that says all contrib modules are at pgfoundry or whatever. I'm not so sure that's a good idea. I think contrib is a good repository for code that is tightly tied to the backend, or provides extentions to the backen, or is something that will eventually be integrated into the backend, but just isn't ready for prime time yet (pg_autovacuum for example). The value of contrib is exposure. I firmly believe that pg_autovacuum would not have gotten as much testing from gborg as it has from contrib. Perhaps the definition of what should be in contrib should be tightened down, and anything that doesn't meet that definition should be removed, but I think contrib is a good concept. Matthew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
Joshua D. Drake [EMAIL PROTECTED] writes: My personal opinion is that contrib should be removed entirely. That's not real workable for code that is tightly tied to the backend, such as the various GIST index extensions presently in contrib. It's just easier to maintain that code when it's in with the backend. However the replication modules don't seem to have such a linkage, so I have no objection to moving them out. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
On Wed, 21 Apr 2004, Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: My personal opinion is that contrib should be removed entirely. That's not real workable for code that is tightly tied to the backend, such as the various GIST index extensions presently in contrib. It's just easier to maintain that code when it's in with the backend. However the replication modules don't seem to have such a linkage, so I have no objection to moving them out. Agreed ... but I also think that something like pg_autovacuum should be moved to gborg ... there seems to be alot of activity on fixing bugs in it that most ppl won't see until they upgrade to the next release, even though those fixes would be pertinent/useful to their current implementation ... begin able to download/install pg_autovacuum 1.1 would definitely be a good thing, when it was considered stable enoguh for a release ... tsearch, I believe, is maintained somewhere else already, no? same with tsearch2? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
tsearch, I believe, is maintained somewhere else already, no? same with tsearch2? Yes that is correct but I think they commit back to contrib before they release. Realistically, although I did not used to agree, I believe that the only that that should come with PostgreSQL is PostgreSQL and required items for PostgreSQL. IMHO: PostgreSQL should include: PostgreSQL Psql All development headers C/C++ Libs Everything else should be on SourceForge or Gforge or whatever. The possible exception would be the pl stuff. Sincerely, Joshua D. Drake Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
Joe Conway wrote: Jan Wieck wrote: Taking into account that quite a few people have repeatedly stated that the components in contrib are considered more supported/recommended than similar solutions found on gborg or any other external site, I suggest we move the projects dbmirror and dblink to gborg. The rserv contrib module seems to me to be an early Perl prototype of erserver, nobody is working on any more. I suggest we drop that entirely. Comments/alternatives? dblink gets regularly updated as and when things change which affect it in the backend. It is more tightly bond to the backend than a client application, which the replication solutions you mention are. It is not a replication solution anyway, so I'm not sure why you would categorize in that way. None of the replication solutions I see are client applications only. Substantial parts of erserver and Slony for example are loadable modules and stored procedures, tightly bond to the backend by using data and functionality not available via the SPI. So the same problems apply here, which then would be a reason to add them to contrib as well? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
I almost agree, but I think things that are being actively developed to eventually move into the backend, like autovacuum or slony-I should be in contrib. Things that aren't destined for backend integration should be removed though, like pgbench or dblink or whatnot. On Wed, 21 Apr 2004, Joshua D. Drake wrote: Hello, My personal opinion is that contrib should be removed entirely. Just have a contrib.txt that says all contrib modules are at pgfoundry or whatever. Sincerely, Joshua D. Drake Jan Wieck wrote: Taking into account that quite a few people have repeatedly stated that the components in contrib are considered more supported/recommended than similar solutions found on gborg or any other external site, I suggest we move the projects dbmirror and dblink to gborg. The rserv contrib module seems to me to be an early Perl prototype of erserver, nobody is working on any more. I suggest we drop that entirely. Comments/alternatives? Jan ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
The problem with moving all contribs to gborg is that sometimes it's required to change many modules, for example, because of changing GiST interface. Tom saves a lot of working for contrib authors, when he change code in core. I'm not sure, gborg would provide easy access for such kind of things. tsearch2, particularly, is maintained in pgsql CVS. Oleg On Wed, 21 Apr 2004, Joshua D. Drake wrote: tsearch, I believe, is maintained somewhere else already, no? same with tsearch2? Yes that is correct but I think they commit back to contrib before they release. Realistically, although I did not used to agree, I believe that the only that that should come with PostgreSQL is PostgreSQL and required items for PostgreSQL. IMHO: PostgreSQL should include: PostgreSQL Psql All development headers C/C++ Libs Everything else should be on SourceForge or Gforge or whatever. The possible exception would be the pl stuff. Sincerely, Joshua D. Drake Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(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] contrib vs. gborg/pgfoundry for replication solutions
Hello, Well perhaps we can have exceptions. TSearch would be a good exception as it really should be integrated into PostgreSQL anyway. There are very few of these that I think would be an issue. Sincerely, Joshua D. Drake Oleg Bartunov wrote: The problem with moving all contribs to gborg is that sometimes it's required to change many modules, for example, because of changing GiST interface. Tom saves a lot of working for contrib authors, when he change code in core. I'm not sure, gborg would provide easy access for such kind of things. tsearch2, particularly, is maintained in pgsql CVS. Oleg On Wed, 21 Apr 2004, Joshua D. Drake wrote: tsearch, I believe, is maintained somewhere else already, no? same with tsearch2? Yes that is correct but I think they commit back to contrib before they release. Realistically, although I did not used to agree, I believe that the only that that should come with PostgreSQL is PostgreSQL and required items for PostgreSQL. IMHO: PostgreSQL should include: PostgreSQL Psql All development headers C/C++ Libs Everything else should be on SourceForge or Gforge or whatever. The possible exception would be the pl stuff. Sincerely, Joshua D. Drake Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(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] contrib vs. gborg/pgfoundry for replication solutions
IMHO it's not all that important where the source is developed (core cvs, gborg etc) - whichever suits the development/release model best shuold be used (meaning inside core only if it should be released on the very same schedule as the main backend only). What is more important is the exposure of the released versions. I think it should be possible (and fairly easy) for projects developed outside the core to get included in the official download page, meaning go on the ftp site and mirrors. Today it seems ODBC and pgadmin3 go there, but pretty much nothing else (not even JDBC?). Perhaps a good structure there would allow more proejcts to get that kind of exposure, and be easier to find. I quite often get people who claim there is no this or that for pgsql when it's on gborg - simply becauase they didn't find it on the ftp site. If you go looking, you'll find it on gborg, but if you don't know where to look it can be hard. Especially for newcomers. //Magnus -Original Message- From: scott.marlowe [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 21, 2004 10:03 PM To: Joshua D. Drake Cc: Jan Wieck; PostgreSQL-development Subject: Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions I almost agree, but I think things that are being actively developed to eventually move into the backend, like autovacuum or slony-I should be in contrib. Things that aren't destined for backend integration should be removed though, like pgbench or dblink or whatnot. On Wed, 21 Apr 2004, Joshua D. Drake wrote: Hello, My personal opinion is that contrib should be removed entirely. Just have a contrib.txt that says all contrib modules are at pgfoundry or whatever. Sincerely, Joshua D. Drake Jan Wieck wrote: Taking into account that quite a few people have repeatedly stated that the components in contrib are considered more supported/recommended than similar solutions found on gborg or any other external site, I suggest we move the projects dbmirror and dblink to gborg. The rserv contrib module seems to me to be an early Perl prototype of erserver, nobody is working on any more. I suggest we drop that entirely. Comments/alternatives? Jan ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
-Original Message- From: Joshua D. Drake [mailto:[EMAIL PROTECTED] Sent: 21 April 2004 19:16 To: Jan Wieck Cc: PostgreSQL-development Subject: Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions Hello, My personal opinion is that contrib should be removed entirely. Just have a contrib.txt that says all contrib modules are at pgfoundry or whatever. Couldn't agree more. Regards, Dave. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
Marc G. Fournier [EMAIL PROTECTED] writes: On Wed, 21 Apr 2004, Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: My personal opinion is that contrib should be removed entirely. That's not real workable for code that is tightly tied to the backend, such as the various GIST index extensions presently in contrib. It's just easier to maintain that code when it's in with the backend. tsearch, I believe, is maintained somewhere else already, no? same with tsearch2? No, those guys are exactly the sort of backend-dependent code I'm thinking of. Teodor just recently made a GIST API change that affected both the core backend and tsearch (as well as the other GIST modules in contrib). With separate distribution trees that would've been a lot more painful to do. I think the long-term plan for tsearch2, at least, should be full integration rather than separation ... 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] contrib vs. gborg/pgfoundry for replication solutions
People: I almost agree, but I think things that are being actively developed to eventually move into the backend, like autovacuum or slony-I should be in contrib. Things that aren't destined for backend integration should be removed though, like pgbench or dblink or whatnot. I agree with this. Although I point out that, per Jan, Slony does *not* fall in this group. From my perspective, there are 2 criteria for something being in Contrib: 1) is the module tightly tied to particular versions of PostgreSQL, so that the version shipped with 7.4 would not work with 7.5 or with 7.3? 2) Is the module being considered for eventual incorporation into the mainstream backend? That being said, let us get projects.postgresql.org up and running first ... we've hit some technical snags today. -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
On Wed, 21 Apr 2004, Tom Lane wrote: No, those guys are exactly the sort of backend-dependent code I'm thinking of. Teodor just recently made a GIST API change that affected both the core backend and tsearch (as well as the other GIST modules in contrib). With separate distribution trees that would've been a lot more painful to do. I think the long-term plan for tsearch2, at least, should be full integration rather than separation ... But there should be some sort of path to full integration ... isdb_ibbn(sp?) has been there forever, and I canj't see it ever being integrated ... Personally, the neat thing about PostgreSQL is that we are extendible(sp?) quite easily, and stuff like tsearch, earthdistance, postgis, etc all show that very nicely ... why add for the sake of adding? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
On Wed, 21 Apr 2004, scott.marlowe wrote: I almost agree, but I think things that are being actively developed to eventually move into the backend, like autovacuum or slony-I should be in contrib. Things that aren't destined for backend integration should be removed though, like pgbench or dblink or whatnot. Slony-I involves no backend integration that I've seen in its docs ... Jan? Did I miss something? As far as stuff like autovacuum, though ... its something that could definitely benefit from a seperate release cycle from the main code ... Has anyone looked at developing an Installer/packaging system so that as far as the code is concerned, thing are seperate projects, but for the end user ... The thing is, for how many ppl are seperate packages difficult? I know for me, under FreeBSD, I cd to a /usr/ports/databases/pg_autovacuum and type 'make install' and its done ... I thought that stuff like Redhat had the full screen installer that lists things? My point is that all of this stuff shouldn't be in the core CVS ... its a packaging issue, not a cvs one ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
On Wed, 21 Apr 2004, Jan Wieck wrote: Joe Conway wrote: Jan Wieck wrote: Taking into account that quite a few people have repeatedly stated that the components in contrib are considered more supported/recommended than similar solutions found on gborg or any other external site, I suggest we move the projects dbmirror and dblink to gborg. The rserv contrib module seems to me to be an early Perl prototype of erserver, nobody is working on any more. I suggest we drop that entirely. Comments/alternatives? dblink gets regularly updated as and when things change which affect it in the backend. It is more tightly bond to the backend than a client application, which the replication solutions you mention are. It is not a replication solution anyway, so I'm not sure why you would categorize in that way. None of the replication solutions I see are client applications only. Substantial parts of erserver and Slony for example are loadable modules and stored procedures, tightly bond to the backend by using data and functionality not available via the SPI. So the same problems apply here, which then would be a reason to add them to contrib as well? Why is it the core developers responsibility to make sure that an application stays in sync with the main tree? Personally, that is giving life to software that could just as easily be unused by anyone, but kept in the code base because a commit was made to it less then 6 months ago ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
On Thu, 22 Apr 2004, Magnus Hagander wrote: IMHO it's not all that important where the source is developed (core cvs, gborg etc) - whichever suits the development/release model best shuold be used (meaning inside core only if it should be released on the very same schedule as the main backend only). What is more important is the exposure of the released versions. I think it should be possible (and fairly easy) for projects developed outside the core to get included in the official download page, meaning go on the ftp site and mirrors. Today it seems ODBC and pgadmin3 go there, but pretty much nothing else (not even JDBC?). Perhaps a good structure there would allow more proejcts to get that kind of exposure, and be easier to find. I see no reaosn why projects can't be mirrored into the main ftp server, and brought through the mirrors ... I quite often get people who claim there is no this or that for pgsql when it's on gborg - simply becauase they didn't find it on the ftp site. If you go looking, you'll find it on gborg, but if you don't know where to look it can be hard. Especially for newcomers. ftp://gborg.postgresql.org/pub - ls everything is listed there ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
The thing is, for how many ppl are seperate packages difficult? I know for me, under FreeBSD, I cd to a /usr/ports/databases/pg_autovacuum and type 'make install' and its done ... I thought that stuff like Redhat had the full screen installer that lists things? Well, if setup correctly for redhat, debian or even SuSE you would type: apt-get install pg_autovacuum or with redhat you might also do yum install pg_autovacuum But that is packaging and that is up to the developers of the particular project. Joshua D. Drake My point is that all of this stuff shouldn't be in the core CVS ... its a packaging issue, not a cvs one ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
Marc G. Fournier wrote: On Wed, 21 Apr 2004, scott.marlowe wrote: I almost agree, but I think things that are being actively developed to eventually move into the backend, like autovacuum or slony-I should be in contrib. Things that aren't destined for backend integration should be removed though, like pgbench or dblink or whatnot. Slony-I involves no backend integration that I've seen in its docs ... Jan? Did I miss something? Slony-I is intended to be PG version independent as much as possible. It would rather hurt to move it into contrib. Sure are there backend dependencies to #ifdef/#else, but for Slony-I this is considered a strength, not a problem. How else would it be possible to use Slony-I to do a PostgreSQL major version upgrade of multi-GB databases with only a few seconds interruption? As far as stuff like autovacuum, though ... its something that could definitely benefit from a seperate release cycle from the main code ... Has anyone looked at developing an Installer/packaging system so that as far as the code is concerned, thing are seperate projects, but for the end user ... The thing is, for how many ppl are seperate packages difficult? I know for me, under FreeBSD, I cd to a /usr/ports/databases/pg_autovacuum and type 'make install' and its done ... I thought that stuff like Redhat had the full screen installer that lists things? I think most of the current contrib projects are more missing the advantage version independence would have for the ease of sitting in contrib and having the whole project management around them just done. Yes, doing your own gborg project costs time. You have to maintain pages, do your own release cycles with announcement, BETA phase, tarballs, packaging and all the nine yards. Being in contrib avoids all that in a very convenient way. My point is that all of this stuff shouldn't be in the core CVS ... its a packaging issue, not a cvs one ... Exactly. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
I think most of the current contrib projects are more missing the advantage version independence would have for the ease of sitting in contrib and having the whole project management around them just done. Yes, doing your own gborg project costs time. You have to maintain pages, do your own release cycles with announcement, BETA phase, tarballs, packaging and all the nine yards. Being in contrib avoids all that in a very convenient way. I think Gnome (and KDE) have the right idea. Several independent small projects that once or twice a year get together and have a big release. We could co-ordinate a set of projects (phppgadmin, pgadmin, slony, jdbc, odbc, etc. etc.) to make a release on the same day as PostgreSQL. We then setup several 'meta' packages. For example, PostgreSQL-lite might be just the core. PostgreSQL-Advanced might include jdbc, pgadmin, slony, tsearch, postgis and everything in postgresql-lite. Those who know what they want would be free to install the individual packages just like with Gnome you can install epiphany and it'll pull in everything needed for it without any extras. I suppose one trick is allowing things like Postgis to be compiled without requiring the source code to be around -- although I suppose we could suggest a postgresql-headers package which Mozilla did that for a while. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
On Wed, 21 Apr 2004, Rod Taylor wrote: I think most of the current contrib projects are more missing the advantage version independence would have for the ease of sitting in contrib and having the whole project management around them just done. Yes, doing your own gborg project costs time. You have to maintain pages, do your own release cycles with announcement, BETA phase, tarballs, packaging and all the nine yards. Being in contrib avoids all that in a very convenient way. I think Gnome (and KDE) have the right idea. Several independent small projects that once or twice a year get together and have a big release. We could co-ordinate a set of projects (phppgadmin, pgadmin, slony, jdbc, odbc, etc. etc.) to make a release on the same day as PostgreSQL. We then setup several 'meta' packages. For example, PostgreSQL-lite might be just the core. PostgreSQL-Advanced might include jdbc, pgadmin, slony, tsearch, postgis and everything in postgresql-lite. I'd like to agree with this concept, but it falls way short of addressing the problem ... and the problem isn't even pulling things out of contrib ... there are alot of good projects out there that aren't on gforge or in the core distribution that ppl just aren't finding ... a 'Meta Package' doesn't help much, since unless you put *everything* into it that you can possibly find, there is always going to be something missing that someone would find useful ... and if you put everything into it, most ppl would only use a small percentage of what is there ... People keep focusing on how to make a super-meta package ... the problem isn't making one big package that contains it all, it is making sure that what is available is easy to find ... what we need is something like freshmeat that is *only* postgresql software ... Now, Josh et al is working on finishing touches of he Projects web site ... I don't know everything that its able to do, but it does provide a centralized, PostgreSQL specific, place to go to see what is available, as long as ppl use it. Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
Magnus Hagander wrote: IMHO it's not all that important where the source is developed (core cvs, gborg etc) - whichever suits the development/release model best shuold be used (meaning inside core only if it should be released on the very same schedule as the main backend only). What is more important is the exposure of the released versions. I think it should be possible (and fairly easy) for projects developed outside the core to get included in the official download page, meaning go on the ftp site and mirrors. Today it seems ODBC and pgadmin3 go there, but pretty much nothing else (not even JDBC?). Perhaps a good structure there would allow more proejcts to get that kind of exposure, and be easier to find. I quite often get people who claim there is no this or that for pgsql when it's on gborg - simply becauase they didn't find it on the ftp site. If you go looking, you'll find it on gborg, but if you don't know where to look it can be hard. Especially for newcomers. I was thinking about CPAN. They have download stuff, but it installs very easily. I wonder if we should allow gborg projects to interface to our configure output in a way that makes it easier for them to be installed. The gborg is easy for development and releasing, but loses in the easy-of-use category sometimes. -- 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] contrib vs. gborg/pgfoundry for replication solutions
Marc G. Fournier wrote: Why is it the core developers responsibility to make sure that an application stays in sync with the main tree? Personally, that is giving life to software that could just as easily be unused by anyone, but kept in the code base because a commit was made to it less then 6 months ago ... Well, in the case of dblink, consider this: - It is used by a fair number of people -- questions are answered on the lists at least once a week with see contrib/dblink. - It is dependent on backend code to the extent that it cannot be built outside of the contrib folder, unless some backend code is duplicated in the external project. It also has no build system of its own. - dblink-type capability should someday make it into the backend, albeit in the form of something compliant to the SQL/MED spec. This is standard functionality in many of the RDBMSs that Postgres users migrate from, and it is needed by enterprise users. - The maintenance burden on core developers is pretty minimal. Recent examples of where it was touched due to other changes in the backend are: * Tom - sort_mem to work_mem change * me - elog to ereport change * Neil - change to tuplestore_begin_heap declaration These changes were part of the routine grep for all the affected code for the change I'm making, hence almost free (at least in my opinion, I'll let Tom or Neil object if they feel otherwise). Had dblink been on gborg, they (Tom and Neil) never would have seen that their backend change affected it. It might have been weeks or months before anyone noticed that it no longer worked against cvs tip (possibly during beta for the next release). At that point the effort involved in figuring out why it no longer works, while not huge, is certainly not as small as the change-as-you-go approach we have now. I deal with this very issue for PL/R. I have to pay close attention to commit messages or I get bitten. These same arguments apply to other things in contrib, and probably could apply to some that currently are not. In any case, I don't understand what the driver is to kill contrib. I fully agree that it should be maintained (meaning that someone other than core is interested enough to provide patches if non-trivial maintenance is required to keep it compiling), and stuff that is not used or suitably licensed should be removed. The contrib build system ought to be maintained in working order in any case because it makes it far easier to extend Postgres with your own functions. Anyway, just my 2cents. Joe ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] cannot drop active portal
Hackers, While playing with code to enable subtransactions in the storage manager, I run across this strangeness: alvherre=# begin; begin;-- start a subtransaction BEGIN BEGIN alvherre=# drop table foo; -- no such table ERROR: no existe la tabla foo alvherre=# commit; ERROR: cannot drop active portal alvherre=# This happens while PortalDrop() tries to drop an active portal. In this state, I can't do anything else short of closing the connection. But this doesn't happen if I try to run a non-utility bogus statement (SELECT foo); the system then allows me to rollback the transaction. Why is a portal kept active after a utility statement fails? I've been reading tcop/postgres.c but I can't find what's different between utility and non-utility. Any clues? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) People get annoyed when you try to debug them. (Larry Wall) ---(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] contrib vs. gborg/pgfoundry for replication solutions
On Wed, 2004-04-21 at 21:29, Marc G. Fournier wrote: On Wed, 21 Apr 2004, Rod Taylor wrote: I think most of the current contrib projects are more missing the advantage version independence would have for the ease of sitting in contrib and having the whole project management around them just done. Yes, doing your own gborg project costs time. You have to maintain pages, do your own release cycles with announcement, BETA phase, tarballs, packaging and all the nine yards. Being in contrib avoids all that in a very convenient way. I think Gnome (and KDE) have the right idea. Several independent small projects that once or twice a year get together and have a big release. We could co-ordinate a set of projects (phppgadmin, pgadmin, slony, jdbc, odbc, etc. etc.) to make a release on the same day as PostgreSQL. We then setup several 'meta' packages. For example, PostgreSQL-lite might be just the core. PostgreSQL-Advanced might include jdbc, pgadmin, slony, tsearch, postgis and everything in postgresql-lite. I'd like to agree with this concept, but it falls way short of addressing the problem ... and the problem isn't even pulling things out of contrib ... there are alot of good projects out there that aren't on gforge or in the core distribution that ppl just aren't finding ... a 'Meta Package' doesn't help much, since unless you put *everything* into it that you can possibly find, there is always going to be something missing that someone would find useful ... and if you put everything into it, most ppl would only use a small percentage of what is there ... We have the current issue of people not knowing that projects like pgadmin exist or where to find the jdbc drivers. These basic components (and others a large segment uses that are well maintained) should go through a release cycle with the -core including the platform test/report phase and be prominently listed in the downloads area and documentation areas -- just as we do for PostgreSQL proper. Goto http://postgresql.org, now track down the jdbc drivers or how to use them. To a significant portion of our users this is more important than CREATE FUNCTION is and in 7.5 jdbc documentation will be much more difficult to find, but no less important than it used to be. Another issue is organizing the hundreds of addon programs that do everything from parsing logs and various specialized interfaces to schema documentation and special function languages (plsh or plr). With an upcoming windows release coming where the masses will be watching, I think the former is more important at the moment. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
On Wed, 21 Apr 2004, Bruce Momjian wrote: I was thinking about CPAN. They have download stuff, but it installs very easily. I wonder if we should allow gborg projects to interface to our configure output in a way that makes it easier for them to be installed. No, because again that requires you to download a large tar ball just to get the build environment? The gborg is easy for development and releasing, but loses in the easy-of-use category sometimes. So, what we *should* be looking at it some sort of howto on how to setup an autoconf environment ... the basics aren't too hard, its only when you get into the more complicated stuff that only *large* projects tend to get into that it gets particulary confusing ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
On Wed, 21 Apr 2004, Rod Taylor wrote: We have the current issue of people not knowing that projects like pgadmin exist or where to find the jdbc drivers. Agreed ... but makign one big META package isn't going to fix that ... as someone else suggested, put a README file in the contrib directory that points ppl to projects.postgresql.org ... These basic components (and others a large segment uses that are well maintained) should go through a release cycle with the -core including the platform test/report phase and be prominently listed in the downloads area and documentation areas -- just as we do for PostgreSQL proper. *ack* ... now the beta cycle just quadrupled in length ... so we develop for 4 months, and beta for a year while we make sure everyone else's packages work with the -core? Most DBAs that I know will not upgrade based on a .0 release on a production system ... they will wait for at least a .1 release ... between .0 and .1 is when projects like PgAdmin should be doing their testing to make sure that they are good for the new major release ... Goto http://postgresql.org, now track down the jdbc drivers or how to use them. To a significant portion of our users this is more important than CREATE FUNCTION is and in 7.5 jdbc documentation will be much more difficult to find, but no less important than it used to be. Now, out of all of the PostgreSQL users, what % are using JDBC? What % are using ODBC? What percentage of those using JDBC are also using ODBC? What % of those using PgAdmin are also using ODBC? For that matter, how many ppl using JDBC only want to download the .jar file itself, and not the source code? % of Binary-Only PgAdmin users? ODBC driver? The point of projects.postgresql.org is that if someone *is* looking for an addon, they should be pointed to projects.postgresql.org ... if you try and merge everything into the -core distribution, you are either going to miss something that *someone* wants to use at some point, *or* one helluva large tar file to download ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] contrib vs. gborg/pgfoundry for replication solutions
Marc G. Fournier wrote: On Wed, 21 Apr 2004, Bruce Momjian wrote: I was thinking about CPAN. They have download stuff, but it installs very easily. I wonder if we should allow gborg projects to interface to our configure output in a way that makes it easier for them to be installed. No, because again that requires you to download a large tar ball just to get the build environment? The gborg is easy for development and releasing, but loses in the easy-of-use category sometimes. So, what we *should* be looking at it some sort of howto on how to setup an autoconf environment ... the basics aren't too hard, its only when you get into the more complicated stuff that only *large* projects tend to get into that it gets particulary confusing ... There are only a few PostgreSQL developers who can do it, so what are the odds that a single guy who maintains a plugin is going to be able to do it. And you can say it is easy, but it just takes one complex problem to hit you, and with PostgreSQL, and all the shared lib stuff and dynamic loading, lots of it is complex. Let's face it, unbundling is great for release efficiency, but terrible for ease-of-use, and let me also tell you that that is where MySQL shines and is perhaps taking new users from us. No secret there. -- 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] contrib vs. gborg/pgfoundry for replication solutions
On Wed, 21 Apr 2004, Joe Conway wrote: Well, in the case of dblink, consider this: - It is used by a fair number of people -- questions are answered on the lists at least once a week with see contrib/dblink. A fair # of ppl are using erserver/bsd too ... should we add that in too? - It is dependent on backend code to the extent that it cannot be built outside of the contrib folder, unless some backend code is duplicated in the external project. It also has no build system of its own. k, so this one falls under 'too lazy to build a proper build system' - dblink-type capability should someday make it into the backend, albeit in the form of something compliant to the SQL/MED spec. This is standard functionality in many of the RDBMSs that Postgres users migrate from, and it is needed by enterprise users. dblink isn't an integrated replication solution, it is a standalone one ... to date, I have not seen one replication solution that solves all the issues, and unless someone comes up with the be all, end all replication solution, none of them should be considered 'part of the backend' ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
Joe Conway wrote: Marc G. Fournier wrote: Why is it the core developers responsibility to make sure that an application stays in sync with the main tree? Personally, that is giving life to software that could just as easily be unused by anyone, but kept in the code base because a commit was made to it less then 6 months ago ... Well, in the case of dblink, consider this: - It is used by a fair number of people -- questions are answered on the lists at least once a week with see contrib/dblink. - It is dependent on backend code to the extent that it cannot be built outside of the contrib folder, unless some backend code is duplicated in the external project. It also has no build system of its own. Both very valid points and together they indicate a decision point ... - dblink-type capability should someday make it into the backend, albeit in the form of something compliant to the SQL/MED spec. This is standard functionality in many of the RDBMSs that Postgres users migrate from, and it is needed by enterprise users. ... which is right here. Either dblink is vital, important and clean enough to move into the main backend code, then let's do it. You claim it is vital and important, but not clean? Then you know what to do. [...] In any case, I don't understand what the driver is to kill contrib. I fully agree that it should be maintained (meaning that someone other than core is interested enough to provide patches if non-trivial maintenance is required to keep it compiling), and stuff that is not used or suitably licensed should be removed. The contrib build system ought to be maintained in working order in any case because it makes it far easier to extend Postgres with your own functions. The driver from my point of view is that some things have been sitting in contrib for quite some time that are neither maintained, nor wanted by anyone. Don't take it personal, I just chose dbmirror and dblink because both fall to some degree into the same usage category as Slony, and both are active projects (I hate shooting at sitting ducks). If we can demonstrate that even projects as vital and complex as these two have a turning point where it says into the backend or out of contrib, then things like noupdate or userlock will have a hard time to show any reason to make an exception. Anyway, just my 2cents. Joe Cool ... found 2 cents :-) Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
Bruce Momjian wrote: I was thinking about CPAN. They have download stuff, but it installs very easily. I wonder if we should allow gborg projects to interface to our configure output in a way that makes it easier for them to be installed. Now that idea I like. The R project also has something similar that allows a standard R command to download, compile, and install their equivalent to contrib packages. They even have an automated system of testing the contributed packages to ensure they work. If the package doesn't meet certain standards, it is automatically dropped from the link list on the download page. See: http://cran.r-project.org/doc/manuals/R-exts.pdf if you're interested. Very impressive, but also a huge amount of work to set up. The gborg is easy for development and releasing, but loses in the easy-of-use category sometimes. I agree. Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
Joe Conway wrote: Bruce Momjian wrote: I was thinking about CPAN. They have download stuff, but it installs very easily. I wonder if we should allow gborg projects to interface to our configure output in a way that makes it easier for them to be installed. Now that idea I like. The R project also has something similar that allows a standard R command to download, compile, and install their equivalent to contrib packages. They even have an automated system of testing the contributed packages to ensure they work. If the package doesn't meet certain standards, it is automatically dropped from the link list on the download page. See: http://cran.r-project.org/doc/manuals/R-exts.pdf if you're interested. Very impressive, but also a huge amount of work to set up. The gborg is easy for development and releasing, but loses in the easy-of-use category sometimes. I agree. I am thinking they could untar into a directory under pgsgl/ or have a way to point to a 'configure'-run source tree and pull values from there. If you include pg_config.h, or use Makefile.global, you have almost everything you need to compile your own, including flags, configure checks, and the location of the installation directory. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] cannot drop active portal
Alvaro Herrera [EMAIL PROTECTED] writes: Why is a portal kept active after a utility statement fails? I think you've broken AtAbort_Portals ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
Bruce Momjian wrote: I am thinking they could untar into a directory under pgsgl/ or have a way to point to a 'configure'-run source tree and pull values from there. If you include pg_config.h, or use Makefile.global, you have almost everything you need to compile your own, including flags, configure checks, and the location of the installation directory. How hard would it be to have the individual cvs projects such that they could be checked out all in one shot? I'm thinking that if it was easy enough to maintain an up-to-date cvs copy for all the individual projects, then it would be easy to grep the entire mess when making backend changes. That way at least you could determine the extent of the impact when making backend changes. And since they are still individual projects, you don't need to get them all if you're not interested. 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
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
On Thu, Apr 22, 2004 at 12:29:36AM -0400, Bruce Momjian wrote: I am thinking they could untar into a directory under pgsgl/ or have a way to point to a 'configure'-run source tree and pull values from there. If you include pg_config.h, or use Makefile.global, you have almost everything you need to compile your own, including flags, configure checks, and the location of the installation directory. That would work only if they compiled the source themselves, as opposed to using a binary package (which is very common). I'm not sure if installing the postgresql-dev or postgresql-devel package would be enough. If not, maybe pg_config could provide all the necessary info ... -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Hi! I'm a .signature virus! cp me into your .signature file to help me spread! ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
