Re: [HACKERS] 10 weeks to feature freeze (Pending Work)
Sent directly. Anyone else who's interested can have a copy. Just email me. I *think* it's structurally sound. Please tell me if you find a problem. It lacks a lot: proper specification of required security properties, a way to specify different mechanism lists for local, vice TCP, vice SSL connections, authN name to authZ name mapping, most seriously I didn't implement security layers. Lots of debug checking still needed. OTOH it works on MacOS 10.4 G4 client and Intel server. As to the Postgres password database: If you use the DIGEST-MD5 mechanism, then you could get a secure, encrypted connection with no setup except the PG password. Also it would have made it easier for people to migrate from the current stuff to SASL. SASL *could* do everything that *any* of the current auth methods can do (OK, except ident) and then some. I thought that exporting all that code and functionality to a standard library would be a good thing in the long run. The down side is that completely replacing the existing framework would require SASL libraries readily available on *all* platforms that PG supports, and Windows doesn't. The Windows SASL API's turn out to be only available on 2K3 server, and have never been publicly tested for interoperability with the standard Unix library. I still believe in SASL. I know the Cyrus SASL library has become pretty ubiquitous on Unix platforms. I wish there were a simpler C API than Cyrus. Java 1.4.2 and up supports it. There are ways it could be provided on Windows, but not within the level of effort that Magnus or I can devote to the problem. - For GSSAPI, there is published interop code for the Windows SSPI at http://web.mit.edu/jaltman/Public/kfw/gss/. It's more places than SASL is. Down side is it doesn't do much that the current Krb5 code doesn't do. Structurally the GSSAPI mods will be very similar to the SASL ones I already did. On Jan 26, 2007, at 7:16 PM, Stephen Frost wrote: * Henry B. Hotz ([EMAIL PROTECTED]) wrote: If anyone is interested I currently have working-but-incomplete patches to support SASL in C. I've decided not to finish and submit them because the glue code to make configuration reasonable, and to allow use of existing Postgres password databases with the password- based mechanisms is still significant. I'd certainly like to take a look at it. I'm not entirely sure I follow what you mean by 'allow use of existing Postgres password databases'- I'm not sure SASL support requires that ability (after all, if they want to use the 'md5' or similar mechanism they can with the current protocol). Or am I missing something about how the SASL implementation is done or intended to be used? I'd tend to think it'd mainly be used as a mechanism to support other authentication mechanisms which don't use the internal Postgres passwords... Thanks, Stephen The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Proposal: Commit timestamp
Jan Wieck [EMAIL PROTECTED] writes: I think the system I described is a slightly modified Lamport generator. The maximum timestamp of any row updated in this transaction, you can consider that the counters received from other nodes. Then I make sure that the next counter (timestamp) is higher than anything I know so far, and I add cluster-wide unique tie breaker to that. If you know all the timestamps in the system then you don't need timestamps at all, just use a counter that you increment by one each time. Isn't the whole reason people use timestamps is so that you don't have to depend on atomically knowing every timestamp in the system? So two transactions can commit simultaneously on different systems and use the timestamps to resolve conflicts later. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] autovacuum process handling
Hi, Alvaro Herrera wrote: I haven't done that yet, since the current incarnation does not need it. But I have considered using some signal like SIGUSR1 to mean something changed in your processes, look into your shared memory. The autovacuum shared memory area would contain PIDs (or maybe PGPROC pointers?) of workers; so when the launcher goes to check that it notices that one worker is no longer there, meaning that it must have terminated its job. Meaning the launcher must keep a list of currently known worker PIDs and compare that to the list in shared memory. This is doable, but quite a lot of code for something the postmaster gets for free (i.e. SIGCHLD). Sure you do -- they won't corrupt anything :-) Plus, what use are running backends in a multimaster environment, if they can't communicate with the outside? Much better would be, AFAICS, to shut everyone down so that the users can connect to a working node. You are right here. I'll have to recheck my code and make sure I 'take down' the postmaster in a decent way (i.e. make it terminate it's children immediately, so that they can't commit anymore). More involved with what? It does not touch shared memory, it mainly keeps track of the backends states (by getting a notice from the postmaster) and does all the necessary forwarding of messages between the communication system and the backends. It's main loop is similar to the postmasters, mainly consisting of a select(). I meant more complicated. And if it has to listen on a socket and forward messages to remote backends, it certainly is a lot more complicated than the current autovac launcher. That may well be. My point was, that my replication manager is so similar to the postmaster, that it is a real PITA to do that much coding just to make it a separate process. For sure, the replication manager needs to keep running during a restarting cycle. And it needs to know the database's state, so as to be able to decide if it can request workers or not. I think this would be pretty easy to do if you made the remote backends keep state in shared memory. The manager just needs to get a signal to know that it should check the shared memory. This can be arranged easily: just have the remote backends signal the postmaster, and have the postmaster signal the manager. Alternatively, have the manager PID stored in shared memory and have the remote backends signal (SIGUSR1 or some such) the manager. (bgwriter does this: it announces its PID in shared memory, and the backends signal it when they want a CHECKPOINT). Sounds like we run out of signals, soon. ;-) I also have to pass around data (writesets), which is why I've come up with that IMessage stuff. It's a per process message queue in shared memory, using a SIGUSR1 to signal new messages. Works, but as I said, I found myself adding messages for all the postmaster events, so that I've really began to question what to do in which process. Again, thanks for your inputs. Markus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding
Hi, Jim Nasby wrote: Note that those terms only make sense if you limit yourself to thinking the master is pushing data out to the slave... I don't really get the limitation here. It's all about distinguishing between master/slave, origin/replica, local/remote - however you want to call it. I think it'd make the most sense if the name reflected whether the trigger should be fired by a replication process or not; that way it doesn't really matter if it's a master or a slave... I think you are mixing the meaning of multi-master replication vs. a per-transaction 'master' (local transaction / origin node of the txn), which then propagates this transaction to the 'slaves' (remote/replica) of that transaction. This does not have anything to do with the more general multi-master vs. single-master replication distinction, as even in multi-master replication, each transaction must have a 'local' or 'origin' node. Regards Markus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Proposal: Commit timestamp
On 1/27/2007 7:26 AM, Gregory Stark wrote: Jan Wieck [EMAIL PROTECTED] writes: I think the system I described is a slightly modified Lamport generator. The maximum timestamp of any row updated in this transaction, you can consider that the counters received from other nodes. Then I make sure that the next counter (timestamp) is higher than anything I know so far, and I add cluster-wide unique tie breaker to that. If you know all the timestamps in the system then you don't need timestamps at all, just use a counter that you increment by one each time. Isn't the whole reason people use timestamps is so that you don't have to depend on atomically knowing every timestamp in the system? So two transactions can commit simultaneously on different systems and use the timestamps to resolve conflicts later. This assumes that you never lose contact to the cluster or if so, instantly stop all update activity because you are at risk that the counters diverge. This risk is much higher with a simple counter than with a system clock that was in sync at the time of disconnect. With all the disadvantages and the pain factor of an asynchronous multimaster replication system comes one big advantage. You can continue autonomously and let conflict resolution figure it out later. 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 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] windows/ecpg regression tests failing
We seem to have 2 ECPG regression failures on Windows - see below, taken from buildfarm log. Can we either fix ecpg or fix the expected results? cheers andrew *** expected/compat_informix-dec_test-MinGW32.stdoutSat Jan 27 02:34:46 2007 --- results/compat_informix-dec_test.stdout Sat Jan 27 02:59:35 2007 *** *** 69,75 dec[6,7]: 0.00 (r: 0 - cmp: 1) dec[6,8]: 0 (r: 0) dec[6,9]: 0.00 (r: 0 - cmp: 1) - (errno == PGTYPES_NUM_UNDERFLOW) - dec[6,10]: 0 (r: -1) dec[7,1]: r: 0, 0.001 dec[7,2]: r: 0, 0 --- 69,74 *** expected/pgtypeslib-num_test2-MinGW32.stdoutSat Jan 27 02:34:46 2007 --- results/pgtypeslib-num_test2.stdout Sat Jan 27 02:59:43 2007 *** *** 88,94 num[6,7]: 0.00 (r: 0 - cmp: 1) num[6,8]: 0 (r: 0) num[6,9]: 0.00 (r: 0 - cmp: 1) - (errno == PGTYPES_NUM_UNDERFLOW) - num[6,10]: 0 (r: -1) num[6,11]: - (r: 0) num[6,12]: 0.00 (r: 0 - cmp: 0) --- 88,93 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Modifying and solidifying contrib
Hello, With all the recent discussion on contrib modules etc.. I would like to offer the following suggestion. I am willing to do a good portion of the work myself and I can get it done before feature freeze. I will need help with the global make file stuff however so that is one dependency. Add directory /modules Modules are compiled and installed by default but not enabled. Modules in 8.3 currently are: pgrowlocks pg_freespacemap (to be renameed pgfreespacemap to be consistent) pgstattuple pgcrypto xml2 pgbuffercache initagg Requirements for /modules Must go through normal vetting process on -hackers Must include patches to core documentation in Docbook Must include test cases? I don't recall if we have regress for all contrib stuff. Keep directory contrib Contrib is not compiled or installed by default Contrib in 8.3 would be: start-scripts pgbench (which I think really should be a foundry project) vacuumlo (is this even required anymore?) adminpack btree_gist etc... Requirements for /contrib Must go through normal vetting process on -hackers Must includes README Must include test cases? Same questions for modules Thoughts, flames? Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Modifying and solidifying contrib
Joshua D. Drake [EMAIL PROTECTED] writes: With all the recent discussion on contrib modules etc.. I would like to offer the following suggestion. AFAICT you're proposing an entirely cosmetic reclassification of /contrib. Aside from the difficulty of getting agreement on which ones should be in and which out, what does that really buy us? The thing that would be really useful to work on is developing a concrete representation of a module that pg_dump would understand, so that you could e.g. tell it to omit btree_gist from a dump. It might be that just segregating a contrib module into its own schema would be sufficient, or maybe that wouldn't work well because of making people need to deal with long search paths. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Modifying and solidifying contrib
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: With all the recent discussion on contrib modules etc.. I would like to offer the following suggestion. AFAICT you're proposing an entirely cosmetic reclassification of /contrib. For the most part yes. Perception is reality and all. The exception being that modules are installed by default. Aside from the difficulty of getting agreement on which ones should be in and which out, what does that really buy us? True and I am sure that people with more time to waste than I would like to spend days creating a thread that is 500 responses long on why their particular module should be a module or a contrib. The thing that would be really useful to work on is developing a concrete representation of a module that pg_dump would understand, so that you could e.g. tell it to omit btree_gist from a dump. I am offering what I can. It might be that just segregating a contrib module into its own schema would be sufficient, or maybe that wouldn't work well because of making people need to deal with long search paths. I do like the contrib schema idea would could easily be melded into this proposal. I don't like the idea that all of contrib would automatically be included which is one of the reasons I wanted to split this up. Sincerely, Joshua D. Drake regards, tom lane -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] How to configure Postgres to make it not to use (load) opensll crypto libraries.
Sorry for the spam. I am not sure if the email I sent earlier went though as it was before I signed up for this email list. Hi, I am looking for a way via configuration to make Postgres not to use the openssl lib libeay32.dll as I need to delete that library. I basically need to remove any encryption (hash is fine) features (buid-in functions are ok) from my Postgres (8.x) installation. This is quite urgent for me. I would be very grateful if someone in this communicate can reply to this email and help me. Thanks! Tom
Re: [HACKERS] How to configure Postgres to make it not to use (load)
Tom Dong wrote: Sorry for the spam. I am not sure if the email I sent earlier went though as it was before I signed up for this email list. Hi, I am looking for a way via configuration to make Postgres not to use the openssl lib libeay32.dll as I need to delete that library. I basically need to remove any encryption (hash is fine) features (buid-in functions are ok) from my Postgres (8.x) installation. This is quite urgent for me. I would be very grateful if someone in this communicate can reply to this email and help me. You can download the source and recompile without the ssl flag. Sincerely, Joshua D. Drake Thanks! Tom -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] windows/ecpg regression tests failing
On Sat, Jan 27, 2007 at 09:27:59AM -0500, Andrew Dunstan wrote: We seem to have 2 ECPG regression failures on Windows - see below, taken from buildfarm log. Can we either fix ecpg or fix the expected results? Should be fixed now. You're right I simply forgot to update the expected result files for Windows. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] crash on 8.2 and cvshead - failed to add item to the
Heikki Linnakangas [EMAIL PROTECTED] writes: Hmm. There seems to be something wrong in the free space calculation in the algorithm for choosing the right split location. I'll dig deeper, unless someone beats me to it.. I think I found it. The page splitting code didn't take into account that when the new item is the first one on the right page, it also becomes the high key of the left page. The fact that this test case triggered it in 32 bit machines and not on 64 bit machines was a coincidence. Patch attached. Patch applied. I tried Joe's example with the maximum and minimum possible fillfactors, and saw no failure, which may or may not prove a lot. Are you still concerned about the PageGetFreeSpace issue? regards, tom lane ---(end of broadcast)--- TIP 1: 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] DROP FUNCTION failure: cache lookup failed for relation X
I wrote: Michael Fuhr [EMAIL PROTECTED] writes: I've found a situation that causes DROP FUNCTION to fail (tested in 8.1.6, 8.2.1, and 8.3devel): http://archives.postgresql.org/pgsql-hackers/2007-01/msg00937.php Ugh ... I haven't traced this through in detail, but I'm pretty sure the problem arises from the fact that dependency.c traces through auto/internal dependencies before actually starting to do the deletions (and thus before acquiring locks). I looked into this a bit more, and found that it's actually a pretty general issue with the dependency.c code: we delete objects depending on a target object before we delete the target itself. Which is fine, except that we don't try to take out any lock on the target object until we get to the object-type-specific subroutine that's supposed to delete it. I think we could fix this for tables by acquiring lock on a table at the instant it's put into a list for deletion inside dependency.c. That would be enough to fix Michael's problem instance, but what of other types of objects? There doesn't seem to be anything preventing somebody from, say, deleting a function at the same time someone else is creating an operator depending on the function. We mostly don't take locks on non-table objects while working with them, and for the most part this is fairly sane because those objects are defined by a single system catalog row anyway: either you see the row or you don't. But this means that the depended-on object could be gone by the time you finish adding a dependency on it. It seems a general solution would involve having dependency.c take exclusive locks on all types of objects (not only tables) as it scans them and decides they need to be deleted later. And when adding a pg_depend entry, we'd need to take a shared lock and then recheck to make sure the object still exists. This would be localized in dependency.c, but it still seems like quite a lot of mechanism and cycles added to every DDL operation. And I'm not at all sure that we'd not be opening ourselves up to deadlock problems. I'm a bit tempted to fix only the table case and leave the handling of non-table objects as is. Comments? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Modifying and solidifying contrib
On Sat, Jan 27, 2007 at 08:59:47AM -0800, Joshua D. Drake wrote: Hello, With all the recent discussion on contrib modules etc.. I would like to offer the following suggestion. I am willing to do a good portion of the work myself and I can get it done before feature freeze. I will need help with the global make file stuff however so that is one dependency. Add directory /modules Not so great. SQL:2003 has a special meaning for the word module. Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Modifying and solidifying contrib
David Fetter wrote: On Sat, Jan 27, 2007 at 08:59:47AM -0800, Joshua D. Drake wrote: Hello, With all the recent discussion on contrib modules etc.. I would like to offer the following suggestion. I am willing to do a good portion of the work myself and I can get it done before feature freeze. I will need help with the global make file stuff however so that is one dependency. Add directory /modules Not so great. SQL:2003 has a special meaning for the word module. Yeah I saw mention of that in another thread, but I really didn't like the word plugins. Do you have another thought? Extensions? Sincerely, Joshua D. Drake Cheers, D -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 1: 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] Modifying and solidifying contrib
On Jan 28, 2007, at 11:25 , Joshua D. Drake wrote: David Fetter wrote: Not so great. SQL:2003 has a special meaning for the word module. Yeah I saw mention of that in another thread, but I really didn't like the word plugins. Do you have another thought? Extensions? Extensions would tie in nicely with its common use in the docs, especially wrt pgxs: PostgreSQL can be extended by the user in many ways ... PostgreSQL also accepts escape string constants, which are an extension to the SQL standard To use the infrastructure for your extension ... Here is an example that builds an extension module ... They test standard SQL operations as well as the extended capabilities of PostgreSQL. The pgxs docs do use module as well, but as previously mentioned module already has a particular meaning in the spec. Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 1: 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] Modifying and solidifying contrib
PostgreSQL can be extended by the user in many ways ... PostgreSQL also accepts escape string constants, which are an extension to the SQL standard To use the infrastructure for your extension ... Here is an example that builds an extension module ... They test standard SQL operations as well as the extended capabilities of PostgreSQL. The pgxs docs do use module as well, but as previously mentioned module already has a particular meaning in the spec. So what are we thinking here? Along with my suggestion of extensions / contrib that we modify initdb to load an extensions schema with all extensions into template1? Sincerely, Joshua D. Drake Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 1: 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 -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Modifying and solidifying contrib
Joshua D. Drake [EMAIL PROTECTED] writes: So what are we thinking here? Along with my suggestion of extensions / contrib that we modify initdb to load an extensions schema with all extensions into template1? No, I don't think so. If you do that it's effectively moving all that stuff into core, especially if you haven't provided a way to turn it off. I don't plan to hold still for any back-door avenues to suddenly turning large parts of contrib into core code. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Modifying and solidifying contrib
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: So what are we thinking here? Along with my suggestion of extensions / contrib that we modify initdb to load an extensions schema with all extensions into template1? No, I don't think so. If you do that it's effectively moving all that stuff into core, especially if you haven't provided a way to turn it off. O.k. any thoughts there? What if we didn't make the extensions schema PUBLIC? Meaning that explicits rights would have to be given for the extensions to be used by anyone but a super user? Obviously the initdb switch could also be selective: initdb --enable-extensions ? Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Modifying and solidifying contrib
On Sat, Jan 27, 2007 at 09:49:25PM -0800, Joshua D. Drake wrote: Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: So what are we thinking here? Along with my suggestion of extensions / contrib that we modify initdb to load an extensions schema with all extensions into template1? No, I don't think so. If you do that it's effectively moving all that stuff into core, especially if you haven't provided a way to turn it off. O.k. any thoughts there? What if we didn't make the extensions schema PUBLIC? Meaning that explicits rights would have to be given for the extensions to be used by anyone but a super user? Whether they're auto-installable or not, I'd vote for putting each one in its own schema by default. That way, people can get an excellent idea just by looking at what schemas exist what extensions are installed in a given DB, and it's fairly straight-forward to remove the thing simply by dropping the schema cascade. Obviously the initdb switch could also be selective: initdb --enable-extensions If it were an initdb switch, I'd want to have something more like --enable-extension=earthdistance Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Modifying and solidifying contrib
On 1/27/07, Joshua D. Drake [EMAIL PROTECTED] wrote: Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: So what are we thinking here? Along with my suggestion of extensions / contrib that we modify initdb to load an extensions schema with all extensions into template1? No, I don't think so. If you do that it's effectively moving all that stuff into core, especially if you haven't provided a way to turn it off. O.k. any thoughts there? What if we didn't make the extensions schema PUBLIC? Meaning that explicits rights would have to be given for the extensions to be used by anyone but a super user? Obviously the initdb switch could also be selective: initdb --enable-extensions ? Sincerely, Joshua D. Drake I've been listening in on this discussion and it is closely tied to an extension that I would like to try. The only thing holding me back is that I am still far to green on the source code to actually propose the work I would like to do. It makes sense the you would want to include the contrib into the install, but I agree with Tom this isn't something you would want in template1. plpgsql is not even in template1 IIRC. It makes more sense to compile the libraries and have an activation module that can be represented in a pg_dump. Maybe the best way to do this would be to place the SQL that modifies system catalog into a compiled library and call this as a function. The function call could then be placed into the pg_dump if needed. Here is where this ties into what I am working on proposing. I have several custom C functions in a library that I need in a restore/build. It seems like at least a couple times every year a new cluster is built and the Admin forgets to compile the custom functions. He builds the DB and then something doesn't work. The basic idea of my proposal would be to have a function that checks for the existence of C libraries. The next piece I would need would be a mechanism for psql to halt the restore SQL script if these checks failed. Finally I would need to add a switch to tell pg_dump to do the checks first thereby causing the restore to fail, hopefully with a nice message that clues the admin that something is wrong. Yes all of this work so I don't get called after hours yet here I am working on the fix after hours. :-) It seems to me like this might be useful in incorporating an extension/module/whatever into Postgres. -- Kevin Barnard Great Beauty, great strength, and great Riches, are really and truly of no great Use; a right Heart exceeds all. -- Benjamin Franklin
