Re: [HACKERS] [GENERAL] New project launched : PostgreSQL GUI
On Tue, 2006-01-31 at 03:50 -0400, Marc G. Fournier wrote: On Tue, 31 Jan 2006, Tino Wildenhain wrote: Devrim GUNDUZ schrieb: Hi, ... Are you going to work with the underlying system's package manager, or put everything in /usr/local? We'll work with the package manager -- I'm an RPM guy ;) RPM isnt the only packaging system out there ;) I thought that Linux had this 'Linux Standard File System' or some such that described where files were supposed to be installed? Or is this another one of those Standards that nobody follows? :( Package management goes beyond sticking the files in the right place. If that were the only requirement, then tar(1) would be a package manager. As for the Linux Standards Base, that is little more than Red Hat and their like-minded friends getting together in a committee and declaring the way they already do everything to be a standard. Generally the LSB holds the short-term needs of commercial Linux distributors above other considerations. -jwb ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] New project launched : PostgreSQL GUI
Tino Wildenhain wrote: Jonah H. Harris schrieb: I had to deal with an installer written in python and several in Java... IMHO, Java would be a better language for this and you could build off some nice OSS installers that already exist (such as IzPack). Just my 2 cents :) Yes! Use Java for ultimate suckiness of the installer ;) I love to install all X11, Java and stuff on a server to be able to install a package with about 1/10 the size ;) How about postponing choice of implementation language until it's clear what it is that should be implemented ;-) Regards, Thomas Hallgren ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] GRANT/REVOKE: Allow column-level privileges
3) For every privilege descriptor in CPD whose action is INSERT, UPDATE, or REFERENCES without a column name, privilege descriptors are also created and added to CPD for each column C in O for which A holds the corresponding privilege with grant option. For each such column, a privilege descriptor is created that specifies the identical grantee, the identical action, object C, and grantor A. 4) For every privilege descriptor in CPD whose action is SELECT without a column name or method name, privilege descriptors are also created and added to CPD for each column C in O for which A holds the corresponding privilege with grant option. For each such column, a privilege descriptor is created that specifies the identical grantee, the identical action, object C, and grantor A. As I read it, granting a table-level privilege is equivalent to repeating the appropriate column-level privilege for all columns. In other words: For this table: CREATE TABLE tab (c1 int, c2 int, c3 int); This statement: GRANT SELECT ON tab TO grantee; ...also implies: GRANT SELECT (c1) ON tab TO grantee; GRANT SELECT (c2) ON tab TO grantee; GRANT SELECT (c3) ON tab TO grantee; This means that after the following, the grantee should have no privileges on tab.c1 (but should retain them on tab.c2, tab.c3): GRANT SELECT ON tab TO grantee; REVOKE SELECT (c1) ON tab FROM grantee; I don't (do not want to) read that conclusion from above paragraphs, anyone else ? My reasoning is, that you can only revoke what has previously been granted. e.g. grant dba to grantee; cannot be revoked with: revoke select on tab from grantee; for that table I think the paragraphs have only been added to understand what rights you have on each column. Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] New project launched : PostgreSQL GUI Installer for
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tino Wildenhain Sent: 31 January 2006 07:55 To: Rick Gigger Cc: Marc G. Fournier; Joshua D. Drake; Christopher Browne; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] New project launched : PostgreSQL GUI Installer for As was said, a gui to produce postgresql.conf files (off host) can be of value. pgAdmin? Regards, Dave. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] New project launched : PostgreSQL GUI Installer for
Hi, On Mon, 2006-01-30 at 20:41 -0800, Jeffrey W. Baker wrote: How will you do an orderly upgrade from one revision to the next, including all the dependencies? We are still in planning phase, any ideas of how to do that is welcome. How will you distribute security updates? We are still in planning phase, any ideas of how to do that is welcome. I predict this form of installation will cause a great many support headaches as users report problems which are caused by oddball compilers, strange CFLAGS, unreleased or strangely patched versions of shared libraries and headers, and so forth. I can't see a problem in here. We already have platform test results in pgbuildfarm and we have the knowledbase about the configure options, flags etc. in that platforms. Obviously anybody is welcome and able to just write whatever software they feel is needed, but go ahead and count me among the skeptics. The world is not turning around us, and please don't be skeptic on a piece of software that you won't use but some people will. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] New project launched : PostgreSQL GUI Installer for
Hi, On Mon, 2006-01-30 at 19:35 -0800, Christopher Browne wrote: We are actively looking for developers for the project. Please drop me an e-mail if you want to join this project. We will use Python, so you need to be a Python guy to join the project. We are in planning phase, if you join us earlier, we will be able to share more ideas. You'd better define the purpose pretty clearly, as I don't see any purpose that's of value, yet. I agree with Joshua's points here. Think of people who do not want an installation via command line. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] New project launched : PostgreSQL GUI Installer for
Hi, On Tue, 2006-01-31 at 09:15 +, Dave Page wrote: As was said, a gui to produce postgresql.conf files (off host) can be of value. pgAdmin? Installer should produce a postgresql.conf, based on some selections via the interface. Then we will use pgAdmin to edit, improve, etc. postgresql.conf. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] New project launched : PostgreSQL GUI Installer for
-Original Message- From: Devrim GUNDUZ [mailto:[EMAIL PROTECTED] Sent: 31 January 2006 09:25 To: Dave Page Cc: Tino Wildenhain; Rick Gigger; Marc G. Fournier; Joshua D. Drake; Christopher Browne; pgsql-hackers@postgresql.org; Burcu GUZEL Subject: Re: [HACKERS] New project launched : PostgreSQL GUI Installer for Hi, On Tue, 2006-01-31 at 09:15 +, Dave Page wrote: As was said, a gui to produce postgresql.conf files (off host) can be of value. pgAdmin? Installer should produce a postgresql.conf, based on some selections via the interface. Then we will use pgAdmin to edit, improve, etc. postgresql.conf. Yeah, that's pretty much how pgInstaller works - we let initdb create the config file, then tweak some values using some C code. The user can then use pgAdmin (or a text editor) to tweak to taste. Regards, Dave. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] New project launched : PostgreSQL GUI Installer for
Hi, On Tue, 2006-01-31 at 08:34 +0100, Tino Wildenhain wrote: http://pgfoundry.org/projects/pgnixinstaller/ We are actively looking for developers for the project. Please drop me an e-mail if you want to join this project. We will use Python, so you need to be a Python guy to join the project. We are in planning phase, if you join us earlier, we will be able to share more ideas. Might be fun of course. But on unix you usually have some kind of package system anyway - how is the installer supposed to play nicely with them? Yes, We will try to stick the file locations of those package managers. We already have that KB. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(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] [GENERAL] New project launched : PostgreSQL GUI Installer for
Hi, On Tue, 2006-01-31 at 08:36 +0100, Tino Wildenhain wrote: Are you going to work with the underlying system's package manager, or put everything in /usr/local? We'll work with the package manager -- I'm an RPM guy ;) RPM isnt the only packaging system out there ;) I used RPM as an alias to package managers :) Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(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] New project launched : PostgreSQL GUI
Hi, On Mon, 2006-01-30 at 22:45 -0500, Vivek Khera wrote: However none of them are PostgreSQL Installers, none of them has the ability to customize the packages and none of them has the ability to install the community packages, etc. :) You need to take a sniff over at the FreeBSD ports. Lets you build customized install of Pg quite easily, without need for a gui, which none of my big servers have. There are some people who do use GUI on their servers and do not know how to compile a software or do not want to build a software via command line. This is called marketing. :) Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(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] [GENERAL] New project launched : PostgreSQL GUI
Hi, On Mon, 2006-01-30 at 21:27 -0500, Jonah H. Harris wrote: I had to deal with an installer written in python and several in Java... IMHO, Java would be a better language for this and you could build off some nice OSS installers that already exist (such as IzPack). Just my 2 cents :) Bundling Java is a pain, so we'd better stay away from that. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] New project launched : PostgreSQL GUI Installer for
Dave Page schrieb: ... As was said, a gui to produce postgresql.conf files (off host) can be of value. pgAdmin? Well, strictly spoken a gui text editor is a gui... but I rather had in mind something guided with buttons, select boxes and stuff and references to documentation, calculations and the like. :-) Tino ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] New project launched : PostgreSQL GUI Installer for
-Original Message- From: Tino Wildenhain [mailto:[EMAIL PROTECTED] Sent: 31 January 2006 10:53 To: Dave Page Cc: Rick Gigger; Marc G. Fournier; Joshua D. Drake; Christopher Browne; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] New project launched : PostgreSQL GUI Installer for Dave Page schrieb: ... As was said, a gui to produce postgresql.conf files (off host) can be of value. pgAdmin? Well, strictly spoken a gui text editor is a gui... but I rather had in mind something guided with buttons, select boxes and stuff and references to documentation, calculations and the like. :-) Err, yes. pgAdmin? It's somewhat more than a simple text editor. :-) /D ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] New project launched : PostgreSQL GUI Installer for
Dave Page schrieb: ... Well, strictly spoken a gui text editor is a gui... but I rather had in mind something guided with buttons, select boxes and stuff and references to documentation, calculations and the like. :-) Err, yes. pgAdmin? It's somewhat more than a simple text editor. Ah, right ;) Didnt see it in action before :-) Now when I actually load a postgresql.conf file I see what you mean. Nice job :-) Figuring out the correct values for some of the buffers and costs is still a bit tough. Otoh, I guess there is no easy way to predict all these. Regards Tino ---(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] New project launched : PostgreSQL GUI Installer for
Tino Wildenhain wrote: Figuring out the correct values for some of the buffers and costs is still a bit tough. Otoh, I guess there is no easy way to predict all these. pgAdmin has a mechanism to suggest values (currently for autovacuum and listen_address only), which waits for expansion :-) I could think of a wizard that asks decent questions, resulting in proposals. Whether implemented as GUI or not, a questionaire and suggested algorithms to calculate settings (eyeballed from Core) would be a good starting point. Regards, Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [GENERAL] New project launched : PostgreSQL GUI
Devrim GUNDUZ wrote: Hi, On Mon, 2006-01-30 at 21:27 -0500, Jonah H. Harris wrote: I had to deal with an installer written in python and several in Java... IMHO, Java would be a better language for this and you could build off some nice OSS installers that already exist (such as IzPack). Just my 2 cents :) Bundling Java is a pain, so we'd better stay away from that. There's always gcj. It's pretty mature by now. I'm not sure about availability compared to Python though, but I find it hard to believe it would be more painful. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Tab completion of SET TRANSACTION ISOLATION
Some time ago, the tab completion code for the SET command was changed to read the list of available settings from the pg_settings table. This means that by the time you're done completing SET TRANSACTION ISOLATION, you've already sent a query and the command will be disallowed. It's not a major issue, but I figured I'd mention it since it confused me a while ago. If someone has an ingenious plan for working around this, let me know. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Want to add to contrib.... xmldbx
Marc G. Fournier wrote: I'm one of the 'foundry admin team', and I can definitely state that we have been accepting projects as ppl are proposing them ... as to gborg-pgfoundry, the only thing that has been holding that up is that the two systems are not compatible at the DB end of things, so moving ppl over isn't the easiest thing to do ... but, for those that have approached us asking to be migrated, we've worked at migrating those over manually ... Speaking of which, is there anything I can do to help migrating PL/Java? I've asked before but we never managed to agree on what efforts that were needed. Regards, Thomas Hallgren ---(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] New project launched : PostgreSQL GUI Installer for
Hi, On Mon, 2006-01-30 at 19:35 -0800, Christopher Browne wrote: We are actively looking for developers for the project. Please drop me an e-mail if you want to join this project. We will use Python, so you need to be a Python guy to join the project. We are in planning phase, if you join us earlier, we will be able to share more ideas. You'd better define the purpose pretty clearly, as I don't see any purpose that's of value, yet. I agree with Joshua's points here. Think of people who do not want an installation via command line. When virtually every flavour of Unix has its own package manager, I have difficulty distinguishing this from the badness of how Oracle's installer handles things. The people I imagine would be of interest as plausible new users are the ones that don't want to be troubled with configuring pretty well anything at all, command line or no. The sort of thing that would get PostgreSQL much more widely deployed would be (for instance) for applications like GnuCash or components of GNOME/KDE to adopt it as their storage mechanism. Their developers are not particularly interested in doing a lot of DBA work, e.g. - setting up users, pg_hba.conf, and such. (The need for this is one of the reasons the GnuCash people have been biasing towards SQLite...) It's worth noting that GNOME/KDE projects have NOT attempted to build their own GUI installers except in the forms of very platform-specific things. In that regard, they let each platform have its own set of idioms. -- let name=cbbrowne and tld=gmail.com in String.concat @ [name;tld];; http://cbbrowne.com/info/slony.html CBS News report on Fort Worth tornado damage: Eight major downtown buildings were severely damaged and 1,000 homes were damaged, with 95 uninhabitable. Gov. George W. Bush declared Tarrant County a disaster area. Federal Emergency Management Agency workers are expected to arrive sometime next week after required paperwork is completed. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] New project launched : PostgreSQL GUI
Hi, On Mon, 2006-01-30 at 22:45 -0500, Vivek Khera wrote: However none of them are PostgreSQL Installers, none of them has the ability to customize the packages and none of them has the ability to install the community packages, etc. :) You need to take a sniff over at the FreeBSD ports. Lets you build customized install of Pg quite easily, without need for a gui, which none of my big servers have. There are some people who do use GUI on their servers and do not know how to compile a software or do not want to build a software via command line. This is called marketing. :) I have to wonder if these people, so helpless that they cannot manage their Unix servers without this GUI tool, will be able to get any of the applications installed that were supposed to use the database. From what I can see, this is merely putting off the learning cliff, and possibly in a dangerous way. -- let name=cbbrowne and tld=gmail.com in name ^ @ ^ tld;; http://linuxfinances.info/info/nonrdbms.html Actually, typing random strings in the Finder does the equivalent of filename completion.(Discussion in comp.os.linux.misc on the intuitiveness of commands: file completion vs. the Mac Finder.) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [GENERAL] New project launched : PostgreSQL GUI
Devrim GUNDUZ wrote: Hi, On Mon, 2006-01-30 at 21:27 -0500, Jonah H. Harris wrote: I had to deal with an installer written in python and several in Java... IMHO, Java would be a better language for this and you could build off some nice OSS installers that already exist (such as IzPack). Just my 2 cents :) Bundling Java is a pain, so we'd better stay away from that. There's always gcj. It's pretty mature by now. I'm not sure about availability compared to Python though, but I find it hard to believe it would be more painful. On several occasions, I have installed graphical Python apps; it has never been the bag of worms involved in getting a Java environment into place... -- select 'cbbrowne' || '@' || 'gmail.com'; http://linuxfinances.info/info/wp.html Signs of a Klingon Programmer #7: Klingon function calls do not have 'parameters' -- they have 'arguments' -- and they ALWAYS WIN THEM. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Tab completion of SET TRANSACTION ISOLATION
Peter Eisentraut [EMAIL PROTECTED] writes: Some time ago, the tab completion code for the SET command was changed to read the list of available settings from the pg_settings table. This means that by the time you're done completing SET TRANSACTION ISOLATION, you've already sent a query and the command will be disallowed. It's not a major issue, but I figured I'd mention it since it confused me a while ago. If someone has an ingenious plan for working around this, let me know. Hm, that's a bit nasty. The only plan I can think of involves reading the list of available variable names in advance and keeping it around. However, I'm not sure I want psql issuing such a query at connection startup whether or not the info will ever be used :-( We also have the ability to check the current in-transaction status, so one possibility is to read the variable list only if not within a transaction (and we didn't do it already in the current session). Making the behavior of tab completion be state-dependent may seem like a non-starter, but really it is anyway --- anything involving a query will stop working in a failed transaction. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Tab completion of SET TRANSACTION ISOLATION
Is there any chance for psql opening a new session if it's inside a transaction and use that to do whatever querying is needed ? Just something like the control connection on ftp (analogy not very good). That could cause other surprises though (could fail for example due to too many connections open), and I have no idea about psql internals so it might be completely against it's philosophy... Cheers, Csaba. On Tue, 2006-01-31 at 15:29, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Some time ago, the tab completion code for the SET command was changed to read the list of available settings from the pg_settings table. This means that by the time you're done completing SET TRANSACTION ISOLATION, you've already sent a query and the command will be disallowed. It's not a major issue, but I figured I'd mention it since it confused me a while ago. If someone has an ingenious plan for working around this, let me know. Hm, that's a bit nasty. The only plan I can think of involves reading the list of available variable names in advance and keeping it around. However, I'm not sure I want psql issuing such a query at connection startup whether or not the info will ever be used :-( We also have the ability to check the current in-transaction status, so one possibility is to read the variable list only if not within a transaction (and we didn't do it already in the current session). Making the behavior of tab completion be state-dependent may seem like a non-starter, but really it is anyway --- anything involving a query will stop working in a failed transaction. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] New project launched : PostgreSQL GUI Installer for
Devrim GUNDUZ wrote: Hi, On Mon, 2006-01-30 at 19:35 -0800, Christopher Browne wrote: We are actively looking for developers for the project. Please drop me an e-mail if you want to join this project. We will use Python, so you need to be a Python guy to join the project. We are in planning phase, if you join us earlier, we will be able to share more ideas. You'd better define the purpose pretty clearly, as I don't see any purpose that's of value, yet. I agree with Joshua's points here. Think of people who do not want an installation via command line. Surely the only people installing from the command-line are those that want to. There's synaptic or yum or whatever to let you search for postgresql and handle all your dependencies for you. I mean *I* compile from source when I'm testing betas or want to backport and there's no package but I can't imagine most Ubuntu users bother. Now something to let you install extra modules, tune your postgresql.conf and pg_hba.conf - that's useful. If it can explain as it goes along, all the better (like bastille linux?) -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New project launched : PostgreSQL GUI Installer for
J. Andrew Rogers wrote: snip A graphical installer for Unix is fine, but please, do not make it anything like Oracle's graphical installer. Oracle's graphical install process gives command line installs a good name for ease of use. J. Andrew Rogers I heartily second that! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Want to add to contrib.... xmldbx
On Mon, Jan 30, 2006 at 04:35:15PM -0500, Mark Woodward wrote: It gets so frustrating sometimes, it isn't so black and white, there are many levels of gray. The PostgreSQL project is trying so hard to be neutral, that it is making itself irrelevant. Designing and including features that a large group of users would like to have makes sense. Regardless of my extension, I'd love to see PostgreSQL get a little pro-active in positioning itself better. Firstly, there's a reason why some of the projects were included before and have since been removed: Including stuff that depends on PHP in PosstgreSQL causes build dependancy loops. You have to have PHP installed to compile PostgreSQL and you need to have PostgreSQL installed to compile PHP. The only way to solve it is to not mix things like that. Not to mention that your release cycles are then intertwined, which is the wrong thing for most projects. The dependency thing is a HUGE problem in general, the solution to which is not removing cooperation between packages, but through published and standardized APIs. Of all the crap that Microsoft gets wrong, they have the right idea when it comes to standarized APIs. A Windows program written for Windows 95, 11 years ago, runs perfectly fine on Windows XP. the libpq is a pretty good example as well, as long as the API stays standard, everything behind it can move all over the place. I don't understand what you mean by PostgreSQL trying to be neutral. Postgres focuses on what it's good at, being a database. It's not really for or against anything. The PostgreSQL team is not interested in maintaining code that so clearly falls outside of the scope. That is more or less what I'm writing about. I wish people wouldn't take it as an insult or slam, because it isn't. (I keep saying, I think PostgreSQL is amazing, and I've been using it for about a decade.) The source code to PostgreSQL implements a SQL database, the PostgreSQL Project defines a community creating and using this database. Is the scope the source code or is the scope The Postgresql Project? I think it can be said that getting more people using PostgreSQL is within the scope of The PostgreSQL Project. As the open source model promises, we trust that the more people who use PostgreSQL the better off The PostgreSQL Project will be. The better The PostgreSQL Project is, theoretically, the more numerous the resources for the project will become, makeing the community better able to improve the source code. The community is an important part of scope. Secondly, if there is a large group of users who want this, why doesn't someone do it? Hello? Any one of them could take the source, and produce a bundle (say a PostgresPHP Plus Pack) that has all the features you think should be in there. If they can demonstrate they can maintain it, perhaps the postgresql website can host it the same way it hosts the windows installer packages (they're not part of postgres either). There is a difference between having an after market part and being included in the OEM version. This is the IE vs Netscape argument. If people can download Netscape for free, why was IE pre-installed a problem? Becuase it is an extra step the user may not want to take or know to take. If something is there for them from the start, it is easier. Secondly, building a new community takes years and resources with no guarentee of success, if there are existing communities with fundimentally similar goals, it makes more sense to become part of a larger community than it does to create a new one. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Want to add to contrib.... xmldbx
On Mon, 30 Jan 2006, Mark Woodward wrote: It gets so frustrating sometimes, it isn't so black and white, there are many levels of gray. The PostgreSQL project is trying so hard to be neutral, that it is making itself irrelevant. We are making ourselves irrelevant because we encourage the use of PgFoundry vs including everything (and the kitchen sink) in our core distribution? You know, like CPAN, BSD ports, and other sorts of things, I don't have a problem with pgfountry, per se', but who but hackers knows what it is? pgfoundry would be amazing if you called attention to it. I am reminded of Douglas Adams, I Eventually found it, in a disused lavatory in a locked file cabinaet with a sign on it saying, 'beware of the leopod' or something like that. On the home page, pgFoundry, is between Mailing Lists and Techdocs, who's going to see it, and who would even know what pgFoundry means? Only the very curious with spare time on their hands. In PostgreSQL's download page, you do mention a few select projects under the heading Other Software Squirrelmail puts their plugins right next to download. Drupal puts a modules tab right next to the project tab. That's like saying that Perl is makign itself irrelevant since it doesn't include all of CPAN in their distribution, or PHP cause they don't include all of the pear stuff, or ... CPAN is amazing. If an extension is programmed properly, there is no reason why it can't be external to the core distribution, and the tools are provided to help ensure that they are programmed properly ... its not like it used to be, where you *had* to download the source tar ball in order to make use of the Makefile infrastructure ... Yes, creating an extension has improved quite a bit, pg_config should handle more of the standards options like --prefix, but it has improved quite a bit. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Want to add to contrib.... xmldbx
Mark Woodward wrote: I don't understand what you mean by PostgreSQL trying to be neutral. Postgres focuses on what it's good at, being a database. It's not really for or against anything. The PostgreSQL team is not interested in maintaining code that so clearly falls outside of the scope. That is more or less what I'm writing about. I wish people wouldn't take it as an insult or slam, because it isn't. (I keep saying, I think PostgreSQL is amazing, and I've been using it for about a decade.) The source code to PostgreSQL implements a SQL database, the PostgreSQL Project defines a community creating and using this database. Is the scope the source code or is the scope The Postgresql Project? I think it can be said that getting more people using PostgreSQL is within the scope of The PostgreSQL Project. As the open source model promises, we trust that the more people who use PostgreSQL the better off The PostgreSQL Project will be. The better The PostgreSQL Project is, theoretically, the more numerous the resources for the project will become, makeing the community better able to improve the source code. The community is an important part of scope. There clearly is a difference, but you started this Mark by asking to bundle your xmldbx with the core distribution (into contrib) - thus implying source code. Now - there might well be a good argument for an xmldbx package that users can one-click install. Since I've got dozens of xxx-pgsql packages available this way on my Ubuntu desktop, I'm guessing you're thinking more of Windows. So, if we reword your question: Is there, or should there be a simple way to download and install packages/plugins for PostgreSQL via the installer? Now you've got No and Yes as your answers, but that's got nowt to do with contrib/. Of course, there's still the small issue of implementation... -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] New project launched : PostgreSQL GUI Installer for
On Jan 31, 2006, at 12:54 AM, Tino Wildenhain wrote: Rick Gigger schrieb: I don't see why anyone has a problem with this. I am certainly never going to use it but if it helps someone who isn't a linux person to use it on a project when they would have used something else (like mysql) or if it convinces someone to run postgres on linux instead of windows because they now have a graphical installer on linux then it seems like a good thing to me. More users = bigger community = larger potential pool of people to help out. Even if people can't code they can answer newbie (or advanced) questions on the mailing lists or write documentation or even just tell their dba friends about it. The more people using postgres the better. If this will help then I'm all for it. Just because I would rather do a ./ configure make make install doesn't mean that thats the best route for everyone. As was said, a gui to produce postgresql.conf files (off host) can be of value. Also for the tune-people a package builder can be useful too. For other people - if they dont learn a bit about their package system on their choosen system - they will run into other problems soon or later. Why would the necessarily have to run into problem with their packaging system. If someone installs from source it doesn't cause problems with packaging systems. Why should this have to be any different? ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Vacuum and Hash Tables
Hi, Currently, i'm helping out in a project testing the cache miss rates for different buffer replacement policies. I've tried asking the postgresql channel on IRC but was directed to this mailing list instead. At the moment, i've replaced freelist.c with an implementation of the LRU policy and test runs of this policy independant of the server appears to show that it works as expected. I run into problems however, when i attempt to initialise the template1. The code returns vacuuming database template1... FATAL: shared buffer hash table corrupted I suspect that this has something to do with the hashtables that i've used in buf_tables.c and the vacuum. Can anyone point me to any resources that might shed more light on this? Incidently, the code base i'm using is version 8.0.4 Regards, Joseph
Re: [HACKERS] Policy on schema-qualified names
On Mon, Jan 30, 2006 at 05:10:03PM -0500, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Joachim Wieland wrote: I wonder if there is a policy on when schema-qualified names should be used in ereport/elog messages. If it's not too hard to do, I would add the schema name in most places. Actually, it's semi-consciously omitted in most places on the grounds that (1) it's seldom necessary to identify the problem, and (2) in many error messages it would contribute to violating the make it fit on one line style guideline. (1) is probably true but it wouldn't hurt to include the schema name there either. Making assumptions on the length of an error message seems to be moot anyway, since you don't know the length of the names of user defined objects in advance, nor do you know the length of the translated message strings in different languages. So you just lose precision for a questionable gain. Joachim ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Policy on schema-qualified names
Joachim Wieland [EMAIL PROTECTED] writes: Making assumptions on the length of an error message seems to be moot anyway, since you don't know the length of the names of user defined objects in advance, nor do you know the length of the translated message strings in different languages. It's certainly all pretty fuzzy, but adding an additional name to an error message has to be seen as a significant increase in the message length. The worst cases are for things like foreign-key messages, where you'd be putting *two* additional identifiers into the message. I think the precision argument is misguided. The direction that we ought to be going in is to add separate fields to error reports that contain just the names of the relevant objects (without any other decoration). This is needed anyway to allow client-side programs to extract the information without having to parse human-readable text messages ... and IIRC it's required by some part of the SQL spec, too. I imagine such fields wouldn't be shown at default verbosity, but you could look at them if you needed to find out which schema a referenced object belonged to. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] New project launched : PostgreSQL GUI
Christopher Browne wrote: Devrim GUNDUZ wrote: Hi, On Mon, 2006-01-30 at 21:27 -0500, Jonah H. Harris wrote: I had to deal with an installer written in python and several in Java... IMHO, Java would be a better language for this and you could build off some nice OSS installers that already exist (such as IzPack). Just my 2 cents :) Bundling Java is a pain, so we'd better stay away from that. There's always gcj. It's pretty mature by now. I'm not sure about availability compared to Python though, but I find it hard to believe it would be more painful. On several occasions, I have installed graphical Python apps; it has never been the bag of worms involved in getting a Java environment into place... Install gcj and you're up and running, graphics and all. What's the problem (besides your obvious aversion to Java)? Or take it one step further and use gcj to compile the Java code into statically linked binaries. Where's the pain, really? Regards, Thomas Hallgren ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] New project launched : PostgreSQL GUI Installer for
On Mon, Jan 30, 2006 at 08:53:54PM -0800, Joshua D. Drake wrote: If I could install Oracle on Debian/AMD64 with a shell script, I'd drop Postgresql in a heartbeat. Obviously anybody is welcome and able to just write whatever software they feel is needed, but go ahead and count me among the skeptics. The installer is for the 98% not the 2%. You are in the 2%. I've yet to find *anyone* who likes the Oracle installer. It's absolutely the last thing I would use as a point of reference. Come to think of it, the DB2 installer was a pile of crap as well... My concern with this installer is that people are going to show up in -general or on IRC in droves with dependancy related problems with the installer. IMO it would be *much* better if we instead focused on something that made it easy to install stuff out of contrib and/or pgFoundry (and prefferably could be used without a GUI). But, OSS works by people scratching itches, so if there's folks who want to scratch this itch... -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(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] New project launched : PostgreSQL GUI Installer for
On Tue, Jan 31, 2006 at 11:46:03AM +, Andreas Pflug wrote: Tino Wildenhain wrote: Figuring out the correct values for some of the buffers and costs is still a bit tough. Otoh, I guess there is no easy way to predict all these. pgAdmin has a mechanism to suggest values (currently for autovacuum and listen_address only), which waits for expansion :-) I could think of a wizard that asks decent questions, resulting in proposals. Whether implemented as GUI or not, a questionaire and suggested algorithms to calculate settings (eyeballed from Core) would be a good starting point. PostgreSQL *desperately* needs a better means of dealing with configuration (though I guess I shouldn't be pushing too hard for this since the current state of affairs brings me business). Any improvement in this area would be very welcome. http://pgfoundry.org/projects/configurator/ is something worth looking at. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Tab completion of SET TRANSACTION ISOLATION
On Tue, Jan 31, 2006 at 03:41:06PM +0100, Csaba Nagy wrote: Is there any chance for psql opening a new session if it's inside a transaction and use that to do whatever querying is needed ? Just something like the control connection on ftp (analogy not very good). That could cause other surprises though (could fail for example due to too many connections open), and I have no idea about psql internals so it might be completely against it's philosophy... Well, one problem there is that the connection could well have different parameters, like search_path. Granted, probably wouldn't matter in this case, but... Plus of course there's the cost of startup. Something that's asked for periodically is the ability to run things outside of a current transaction. The normal reply is to use DBLink, but if there was backend support for that it could probably be used here. But I suspect adding that ability would be a pretty large amount of work :( -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Policy on schema-qualified names
On Tue, Jan 31, 2006 at 01:46:42PM -0500, Tom Lane wrote: The direction that we ought to be going in is to add separate fields to error reports that contain just the names of the relevant objects (without any other decoration). This is needed anyway to allow client-side programs to extract the information without having to parse human-readable text messages ... and IIRC it's required by some part of the SQL spec, too. Agreed. I didn't know about that part but with this in mind it would be a waste of time to check all of the the messages at this time and make them conform in some way. Thanks for the explanation, Joachim ---(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] Configuration WAS: New project launched : PostgreSQL GUI Installer for
Jeffery, PostgreSQL *desperately* needs a better means of dealing with configuration (though I guess I shouldn't be pushing too hard for this since the current state of affairs brings me business). Any improvement in this area would be very welcome. http://pgfoundry.org/projects/configurator/ is something worth looking at. An ideal facility would be a program that analyzes the workload at runtime and adjusts accordingly. That doesn't sound too hard, within some unambitious boundary. If anyone would like to work on this, I'd be happy to contribute. It seems pretty hard to *me*, compared with static configuration. If you have ideas for runtime analysis of configuration criteria, I'd be thrilled to hear them. From my perspective, most of them depend on backend monitoring that we don't have yet (like querying how full the FSM is). -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Tab completion of SET TRANSACTION ISOLATION
Michael Paesold wrote: Perhaps not multiple connections, but multiple transactions per connection, like Oracle supports, AFAIK. All with a big ;-) of course. I doubt it would be easy to implement that. The assumption one-connection-has-one-transaction is probably pretty deeply burried in many backend components. Has this been changed by the prepared-transactions stuff? I may be mistaken, which would be very positive news. No, you're not mistaken. The 2PC stuff works by reassigning the transaction to a sort-of phantom backend. -- Alvaro Herrerahttp://www.advogato.org/person/alvherre Llegará una época en la que una investigación diligente y prolongada sacará a la luz cosas que hoy están ocultas (Séneca, siglo I) ---(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] Configuration WAS: New project launched : PostgreSQL
On Tue, 2006-01-31 at 12:11 -0800, Josh Berkus wrote: Jeffery, PostgreSQL *desperately* needs a better means of dealing with configuration (though I guess I shouldn't be pushing too hard for this since the current state of affairs brings me business). Any improvement in this area would be very welcome. http://pgfoundry.org/projects/configurator/ is something worth looking at. An ideal facility would be a program that analyzes the workload at runtime and adjusts accordingly. That doesn't sound too hard, within some unambitious boundary. If anyone would like to work on this, I'd be happy to contribute. It seems pretty hard to *me*, compared with static configuration. If you have ideas for runtime analysis of configuration criteria, I'd be thrilled to hear them. From my perspective, most of them depend on backend monitoring that we don't have yet (like querying how full the FSM is). I agree that some instrumentation of the backend might be needed. But several of the performance-critical parameters seem tractable: Effective cache size - should be easy to monitor the system for this Shared buffers - easy to start from a rule-of-thumb and monitor usage Work mem - trace the size and frequency of temp files Wal buffers - trace the average or 80th percentile number of pages generated by transactions Commit delay - track the concurrency level and avg distance btw commits Checkpoint segments - should be very easy to auto-adjust Random page cost - should possible to determine this at runtime Vacuum* - may be possible to determine vacuum impact on concurrent queries ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Configuration WAS: New project launched : PostgreSQL
Jeffrey, I agree that some instrumentation of the backend might be needed. But several of the performance-critical parameters seem tractable: Effective cache size - should be easy to monitor the system for this Shared buffers - easy to start from a rule-of-thumb and monitor usage Work mem - trace the size and frequency of temp files Wal buffers - trace the average or 80th percentile number of pages generated by transactions Commit delay - track the concurrency level and avg distance btw commits Checkpoint segments - should be very easy to auto-adjust Random page cost - should possible to determine this at runtime Vacuum* - may be possible to determine vacuum impact on concurrent queries Great. Wanna join the configurator project? I won't have much time to work on it before March, but anyone with ideas is welcome. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Tab completion of SET TRANSACTION ISOLATION
Tom Lane [EMAIL PROTECTED] writes: Hm, that's a bit nasty. The only plan I can think of involves reading the list of available variable names in advance and keeping it around. However, I'm not sure I want psql issuing such a query at connection startup whether or not the info will ever be used :-( Well, it could just lazily cache the data if it's ever fetched. That would at least limit the occurrence of this problem to only happening once per connection. psql could also hard code SET TRANSACTION ISOLATION specifically. If psql knew that SET TRANS completes to SET TRANSACTION and SET TRANSACTION I completes to SET TRANSACTION ISOLATION it could avoid doing the query at all. That would only fail if someone uses TAB to view the available completions for SET or any shorter string. And since transaction isolation is strangely absent from the list of completions that seems like not such a big concern. If he's doing that he's not going to find it anyways. -- greg ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Configuration WAS: New project launched : PostgreSQL
On Tue, Jan 31, 2006 at 12:36:31PM -0800, Jeffrey W. Baker wrote: Random page cost - should possible to determine this at runtime Before worrying about random_page_cost at all it makes a lot more sense to look at the query cost estimates, some of which are pretty far out of wack. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Configuration WAS: New project launched : PostgreSQL
On Tue, 2006-01-31 at 17:06 -0600, Jim C. Nasby wrote: On Tue, Jan 31, 2006 at 12:36:31PM -0800, Jeffrey W. Baker wrote: Random page cost - should possible to determine this at runtime Before worrying about random_page_cost at all it makes a lot more sense to look at the query cost estimates, some of which are pretty far out of wack. I agree, but this problem is orthogonal, no? ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] New project launched : PostgreSQL GUI Installer for
On Tue, 2006-01-31 at 13:02 -0600, Jim C. Nasby wrote: On Tue, Jan 31, 2006 at 11:46:03AM +, Andreas Pflug wrote: Tino Wildenhain wrote: Figuring out the correct values for some of the buffers and costs is still a bit tough. Otoh, I guess there is no easy way to predict all these. pgAdmin has a mechanism to suggest values (currently for autovacuum and listen_address only), which waits for expansion :-) I could think of a wizard that asks decent questions, resulting in proposals. Whether implemented as GUI or not, a questionaire and suggested algorithms to calculate settings (eyeballed from Core) would be a good starting point. PostgreSQL *desperately* needs a better means of dealing with configuration (though I guess I shouldn't be pushing too hard for this since the current state of affairs brings me business). Any improvement in this area would be very welcome. http://pgfoundry.org/projects/configurator/ is something worth looking at. An ideal facility would be a program that analyzes the workload at runtime and adjusts accordingly. That doesn't sound too hard, within some unambitious boundary. If anyone would like to work on this, I'd be happy to contribute. -jwb ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Tab completion of SET TRANSACTION ISOLATION
Csaba Nagy wrote: Is there any chance for psql opening a new session if it's inside a transaction and use that to do whatever querying is needed ? Just something like the control connection on ftp (analogy not very good). That could cause other surprises though (could fail for example due to too many connections open), and I have no idea about psql internals so it might be completely against it's philosophy... Perhaps not multiple connections, but multiple transactions per connection, like Oracle supports, AFAIK. All with a big ;-) of course. I doubt it would be easy to implement that. The assumption one-connection-has-one-transaction is probably pretty deeply burried in many backend components. Has this been changed by the prepared-transactions stuff? I may be mistaken, which would be very positive news. Best Regards, Michael Paesold ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Configuration WAS: New project launched : PostgreSQL
On Tue, Jan 31, 2006 at 03:11:50PM -0800, Jeffrey W. Baker wrote: On Tue, 2006-01-31 at 17:06 -0600, Jim C. Nasby wrote: On Tue, Jan 31, 2006 at 12:36:31PM -0800, Jeffrey W. Baker wrote: Random page cost - should possible to determine this at runtime Before worrying about random_page_cost at all it makes a lot more sense to look at the query cost estimates, some of which are pretty far out of wack. I agree, but this problem is orthogonal, no? No. The problem is that random_page_cost has the wrong effect in some of the cost functions, so even if you set it more accurately you're not buying anything. In fact, you might well be hurting performance. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(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] Tab completion of SET TRANSACTION ISOLATION
Added to TODO: o Prevent tab completion of SET TRANSACTION from querying the database and therefore preventing the transaction isolation level from being set. Currently, SET tab causes a database lookup to check all supported session variables. This query causes problems because setting the transaction isolation level must be the first statement of a transaction. --- Greg Stark wrote: Tom Lane [EMAIL PROTECTED] writes: Hm, that's a bit nasty. The only plan I can think of involves reading the list of available variable names in advance and keeping it around. However, I'm not sure I want psql issuing such a query at connection startup whether or not the info will ever be used :-( Well, it could just lazily cache the data if it's ever fetched. That would at least limit the occurrence of this problem to only happening once per connection. psql could also hard code SET TRANSACTION ISOLATION specifically. If psql knew that SET TRANS completes to SET TRANSACTION and SET TRANSACTION I completes to SET TRANSACTION ISOLATION it could avoid doing the query at all. That would only fail if someone uses TAB to view the available completions for SET or any shorter string. And since transaction isolation is strangely absent from the list of completions that seems like not such a big concern. If he's doing that he's not going to find it anyways. -- greg ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: 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] Tab completion of SET TRANSACTION ISOLATION
It could read all the SET variables in at startup? Peter Eisentraut wrote: Some time ago, the tab completion code for the SET command was changed to read the list of available settings from the pg_settings table. This means that by the time you're done completing SET TRANSACTION ISOLATION, you've already sent a query and the command will be disallowed. It's not a major issue, but I figured I'd mention it since it confused me a while ago. If someone has an ingenious plan for working around this, let me know. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Tab completion of SET TRANSACTION ISOLATION
Christopher Kings-Lynne wrote: It could read all the SET variables in at startup? Right, but do we want to do that even if they never ask for a tab completion? I think the easiest might be to just save the list on first tab call. --- Peter Eisentraut wrote: Some time ago, the tab completion code for the SET command was changed to read the list of available settings from the pg_settings table. This means that by the time you're done completing SET TRANSACTION ISOLATION, you've already sent a query and the command will be disallowed. It's not a major issue, but I figured I'd mention it since it confused me a while ago. If someone has an ingenious plan for working around this, let me know. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Tab completion of SET TRANSACTION ISOLATION
On Tue, 2006-01-31 at 20:18 -0500, Bruce Momjian wrote: Christopher Kings-Lynne wrote: It could read all the SET variables in at startup? Right, but do we want to do that even if they never ask for a tab completion? I think the easiest might be to just save the list on first tab call. As mentioned earlier the problem exists for all tab completion in aborted transactions. Perhaps a second database connection could be established during situations when running tab completion and other psql commands is impossible on the main one? -- ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Tab completion of SET TRANSACTION ISOLATION
Rod Taylor wrote: On Tue, 2006-01-31 at 20:18 -0500, Bruce Momjian wrote: Christopher Kings-Lynne wrote: It could read all the SET variables in at startup? Right, but do we want to do that even if they never ask for a tab completion? I think the easiest might be to just save the list on first tab call. As mentioned earlier the problem exists for all tab completion in aborted transactions. Perhaps a second database connection could be established during situations when running tab completion and other psql commands is impossible on the main one? What if you need a password to be supplied? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Tab completion of SET TRANSACTION ISOLATION
On Tue, 2006-01-31 at 20:32 -0500, Rod Taylor wrote: Perhaps a second database connection could be established during situations when running tab completion and other psql commands is impossible on the main one? That would lead to inconsistencies, because of differences between the two sessions -- for example, one session's search path might be different from the other's. -Neil ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Tab completion of SET TRANSACTION ISOLATION
On Tue, 2006-01-31 at 20:53 -0500, Bruce Momjian wrote: Rod Taylor wrote: On Tue, 2006-01-31 at 20:18 -0500, Bruce Momjian wrote: Christopher Kings-Lynne wrote: It could read all the SET variables in at startup? Right, but do we want to do that even if they never ask for a tab completion? I think the easiest might be to just save the list on first tab call. As mentioned earlier the problem exists for all tab completion in aborted transactions. Perhaps a second database connection could be established during situations when running tab completion and other psql commands is impossible on the main one? What if you need a password to be supplied? I believe psql keeps the password in memory. \c seems to be able to change databases without asking for the password again. -- ---(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] Tab completion of SET TRANSACTION ISOLATION
I believe psql keeps the password in memory. \c seems to be able to change databases without asking for the password again. What if that role has a maximum of one connection, etc.? Chris ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Tab completion of SET TRANSACTION ISOLATION
On Wed, 2006-02-01 at 10:28 +0800, Christopher Kings-Lynne wrote: I believe psql keeps the password in memory. \c seems to be able to change databases without asking for the password again. What if that role has a maximum of one connection, etc.? Considering it would only be used when the alternative was to say Sorry, tab completion unavailable, I really don't see these as problems -- fall back to saying it cannot be done. -- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Tab completion of SET TRANSACTION ISOLATION
Rod Taylor [EMAIL PROTECTED] writes: On Wed, 2006-02-01 at 10:28 +0800, Christopher Kings-Lynne wrote: What if that role has a maximum of one connection, etc.? Considering it would only be used when the alternative was to say Sorry, tab completion unavailable, I really don't see these as problems -- fall back to saying it cannot be done. The point is that this can hardly be claimed to be a zero failure mode implementation, any more than is the method of saving the tab completion list after first successful fetch. Since the latter seems far simpler and lower-overhead, I'd go with it... regards, tom lane ---(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] Tab completion of SET TRANSACTION ISOLATION
Peter Eisentraut [EMAIL PROTECTED] writes: Some time ago, the tab completion code for the SET command was changed to read the list of available settings from the pg_settings table. This means that by the time you're done completing SET TRANSACTION ISOLATION, you've already sent a query and the command will be disallowed. Of course, there's always Plan B: revert that patch and go back to a hard-coded list of variable names. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
