Обсуждение: Usability, MySQL, Postgresql.org, gborg, contrib, etc.
A sort of debate started by Bruce about what MySQL does better vs what PostgreSQL could do, then there was a thread about removing "/contrib" from the main download, and a few other posts. I don't think these are unrelated. They all fall under the umbarella of "How does a new user come to use PostgreSQL?" I have come to believe it is a number of issues, it isn't just the site, it isn't just the setup, it isn't whether or not contributed modules are easy to find, I think it is all of these. (1) I think the PostgreSQL web presence has been lacking for some time. I am not a web developer myself, but I do know that the PostgreSQL site does not seem to look and feel like other sites. The new site is better than before, but I think it still needs some more standardization with the rest of the web. There are a lot of "usability" issues that can be fixed easily. Links to the left, fluff items to the right, main message in the middle, symplified menus, etc. Again, while I'm not a web designer, I have a small moch-up of something I think would have more visual "clues" to new users at http://www.mohawksoft.com/PostgreSQL.html (2) Removing the "contrib" directory in the main download. I think this is a good idea, but it means that we need to make it easier to make extensions. I write a lot of extensions and I have a standard Makefile for building them. (Granted I have to change it periodically for different versions) You have to specify the PostgreSQL build directory to build an extension. It isn't clear to me if there is a way to build an extension to PostgreSQL without having built PostgreSQL first. It would be nice if there were a standardized set of extension headers and a well documented process to make an extension. Then we could focus on a standard API. :-) (3) Configuration. What can I say, power users edit postgresql.conf, start scripts, pg_hba.conf, etc. I think it can safely be said, that we need to show non-power users the light. For this, there needs to be an application, in some portable scripting language, that can configure PostgreSQL. Maybe it is in the form of a web server like Samba's SWAT utility, I don't know (A SWAT type utility could run as the PostgreSQL user for the correct rights), but users need this. I don't think the typical debate of "GUI tool aren't really easier" or "That's just bloat" or "Do we even want these users using PostgreSQL" are relevent. If we want to increase usership, this is a requirement. (4) Blessed projects, lets play favorites. Lets find good and meaningful extensions on gborg and ./contrib and work with the authors and make them part of the PostgreSQL "environment." Projects like, replication, .NET service provider, ODBC, pgAdmin, etc. are important and users need to find them close to PostgreSQL's main location. (5) Programming languages. We need to make a programming language standard in PostgreSQL. plpgsql is good, but isn't someone working on a Java language. That would be pretty slick. (6) In keeping with item #4, lets make some Binary distributions and make those available on the mirrors. Think about how a Windows user tries software: Click on a site, install, and run. I could update my Windows installer and console system and create a zipped install. I know there are rpms and debs out there, but if you look at programs like mozilla and realplayer, they have a pretty good installer. Maybe we could use the Mozilla installer? What happend to the Great Bridge installer? When all is said and done, I think the PostgreSQL project lacks a "Product Management" group which steers the public perception and defines usability. This is something *all* other systems have, including MySQL. If we want to make PostgreSQL a wildly popular product, there will be some pain. There should be a "Product Management" group. The leader(s) of this group should be chosen carefully, as he (they) must be free to define what PostgreSQL is. They must have a good feel for product development and understanding of the underlying technology, but not be so techie that we don't address the issues intended. They must be able to rally the troops and direct development efforts. Lastly, he (they) must have the confidence of the core hackers, as it is likely that there will be disagreements with the direction of PostgreSQL, and it wouldn't work if "Product Management" couldn't actually manage what the product was because nobody listened. Is anyone really ready for this sort of commitment?
> -> PL/Java is well and interesting, but requires a barrel of non-free > software, which makes installation and configuration anything but > "slick." > I think it's a bit unfair to say that Pl/Java requires a "barrel of non-free software". Pl/Java doesn't require any software besides the Java Runtime Environment and those who have an interest in Java is *very* likely to have a JRE installed already. I'm currently working on getting Pl/Java running with GNU's GCJ. Aside from a bug in gcj (reported to be fixed by the gcj people), it runs fine with GCJ. At present it requires the HEAD version and the GCJ 3.4 branch from GNU (not released yet). Releases of both are imminent. If PostgreSQL was equipped with an "installer" that modules like Pl/Java could hook into, I'd be more than willing to adhere to whatever requirements such an installer would impose. With the present lack of such semantics, I dare say that the installation is pretty "slick" anyway. Read this and comment http://gborg.postgresql.org/project/pljava/genpage.php?readme. Kind Regards, Thomas Hallgren
"Christopher Browne" <cbbrowne@acm.org> wrote in message news:m3ekqbaec5.fsf@wolfe.cbbrowne.com... > In an attempt to throw the authorities off his trail, pgsql@mohawksoft.com transmitted: > > Is anyone really ready for this sort of commitment? > > By that, I presume you mean... > > "Are people prepared to stop working on the doubtless useful things > that they are working on in favor of spending their time instead on > this set of marketing-oriented systems integration tasks?" > > I think the answer to that is likely a pretty clear NO. > Perhaps more people should be attracted to the project? People that are not just purely technical? I concur with the original posting. Not because of the marketing aspects, but because I think PostgreSQL could benefit greatly if it was more modularized and had a stronger long-term planning. It would ease up a great deal for people like myself who really want to contribute. No "grand restructuring" is needed but more thoughts need to go into modularization and how various things plugs in to PostgreSQL, not just from a technical "how to write the code" perspective, but also from an assembly, deploy, and maintain angle. PostgreSQL has a vast amount of users and the customer base is growing. There is a demand that should not be neglected just because it's "Market Driven". That's not fair the developers that does an excellent job with the product. They really deserve all goodwill they can get from the users. > PostgreSQL runs on numerous systems, and in order to do what you are > proposing, it would be necessary to play system favorites. > > -> Configuration systems are inherently platform-specific. > This is true. But a large part of a configuration system could be made platform independent. If a good modular configuration system was designed and maintained by the PostgreSQL community, I'm pretty sure the platform independent parts of it would see the light of day pretty quickly. Kind regards, Thomas Hallgren
pgsql@mohawksoft.com wrote: > PostgreSQL. Maybe it is in the form of a web server like Samba's SWAT > utility, I don't know (A SWAT type utility could run as the PostgreSQL I've found webmin to be pretty good swat type tool...it's lacking some things to be a full postgres administration system, but I think they have the right idea... > (4) Blessed projects, lets play favorites. Lets find good and meaningful > extensions on gborg and ./contrib and work with the authors and make them > part of the PostgreSQL "environment." Projects like, replication, .NET > service provider, ODBC, pgAdmin, etc. are important and users need to find > them close to PostgreSQL's main location. > > (5) Programming languages. We need to make a programming language standard > in PostgreSQL. plpgsql is good, but isn't someone working on a Java > language. That would be pretty slick. Personally, I like the idea of plphp better. I haven't used either, though. plgsql will always have value in converting oracle deployments, so it is truly hard to standardize on a favorite here. I think the latest versions of pgAdmin are just awesome. I never used to like it very much, but it really is great software. I think any effort expended on beefing that project up is not wasted. Merlin
In an attempt to throw the authorities off his trail, pgsql@mohawksoft.com transmitted: > Is anyone really ready for this sort of commitment? By that, I presume you mean... "Are people prepared to stop working on the doubtless useful thingsthat they are working on in favor of spending their timeinstead onthis set of marketing-oriented systems integration tasks?" I think the answer to that is likely a pretty clear NO. PostgreSQL runs on numerous systems, and in order to do what you are proposing, it would be necessary to play system favorites. -> Configuration systems are inherently platform-specific. -> PL/Java is well and interesting, but requires a barrel of non-free software, which makes installation and configurationanything but "slick." There is _not_ going to be a "Product Management" group any time soon that will turn around PostgreSQL into being a marketing-driven project. I suggest that you instead find projects that are worth doing in their own right without having to make some mandate for a Grand Political Restructuring. Doing individual things that are worthwhile is, obviously, worthwhile. If some point some people in directions that, after some number of such projects, resemble some Grand Political Restructuring, then you'll have succeeded at the latter. Much as you can't push on a rope (unless it's wet and frozen :-)), and can't herd cats (although EDS did a SuperBowl commercial claiming they could), you can't push for a Grand Political Restructuring. The best you can do is lure people in your directions, one cat at a time... -- (format nil "~S@~S" "cbbrowne" "cbbrowne.com") http://cbbrowne.com/info/spreadsheets.html "The theoreticians have proven that this is unsolvable, but there's three of us, and we're smart..." -- Arthur Norman
> >> When all is said and done, I think the PostgreSQL project lacks a >> "Product >> Management" group which steers the public perception and defines >> usability. This is something *all* other systems have, including MySQL. > > Well, NO, not a chance. > > As one of the de-facto heads of our Advocacy group, let me say "you've got > to > be kidding." I don't think so, let me explain below. > > MySQL is a private closed-shop software manufacturer who uses the GPL as > one > of their methods of distribution. They are not a "real" open source > project > -- they are a private, commercial, for-profit software company. I agree, I don't like MySQL all that much. > > We are not. We are a open, 100% voluntary community of contributing > developers and support volunteers. Nobody is going to take orders from a > "Product Manager", that's a position for paid software products > departments. > It would be horribly inappropriate for PostgreSQL, and would destroy > everything that has made us successful to date. You can't give orders to > volunteers. It depends on the volunteers. Some are useless at taking orders, this is true, others, however, are very welcoming to direction. It depends in the individual. Lastly, Bruce, Tom, Peter, and others are very didicated to PostgreSQL. If a real case can be made for a feature, I'm sure they are reasonable enough to see that and grudgingly implement it. Someone, however, has to keep an eye on that ball. > > You're statement that "all other systems" have a Product Manager is also > wildly inaccurate. I think you're thinking of MySQL and Mozilla only. > Heck, even OpenOffice.org doesn't have a Product Manager, and that is a > Sun-sponsored project. Let alone, say, emacs. Or Linux. Linux has Linus, he has a very good eye in the market forces. Emacs, is a non-entity outside UNIX hard core UNIX guys. OpenOffice is very much managed by Sun.
> On Sun, Apr 25, 2004 at 05:15:19PM -0400, pgsql@mohawksoft.com wrote: >> (5) Programming languages. We need to make a programming language >> standard >> in PostgreSQL. plpgsql is good, but isn't someone working on a Java >> language. That would be pretty slick. > > If there's going to be a single standard language, I strongly believe it > should be plpgsql. Any other language means that you have to find > something that someone else knows or is willing to learn, whereas anyone > using a database already knows SQL. plpgsql is simply an extension of > SQL, and is trivial for anyone who's worked with any other database > procedural languages to pickup. Asking a DBA to learn java or perl or > PHP is asking a lot. > > If anything I'd like to see more features brought into plpgsql, like > packages (ala Oracle). Sorry, by standard, I meant installed by default, not to the exclusion of all else.
> In an attempt to throw the authorities off his trail, pgsql@mohawksoft.com > transmitted: >> Is anyone really ready for this sort of commitment? > > By that, I presume you mean... > > "Are people prepared to stop working on the doubtless useful things > that they are working on in favor of spending their time instead on > this set of marketing-oriented systems integration tasks?" > > I think the answer to that is likely a pretty clear NO. That's sort of the question, isn't it? Bruce asked what can "we" learn from MySQL. Well, I've put forth an argument, right or wrong, its my opinion. If there is a concensus that the PostgreSQL team wants to increase user numbers, it is obvious, as evidenced by MySQL, it isn't only about features. The "marketing-oriented systems integration tasks" are arguably *more* important than minor improvements to attain this goal. > > PostgreSQL runs on numerous systems, and in order to do what you are > proposing, it would be necessary to play system favorites. > > -> Configuration systems are inherently platform-specific. Not all that much, java setup programs or a Samba SWAT like program could go a LONG way to improving configurability without suffering platform snobbery. > > -> PL/Java is well and interesting, but requires a barrel of non-free > software, which makes installation and configuration anything but > "slick." > > There is _not_ going to be a "Product Management" group any time soon > that will turn around PostgreSQL into being a marketing-driven > project. No one is saying "Market-driven project," but you must admit, some market savvy would be helpful if you want to get more users. [snip] You know, there were some questions put out to the group wondering how to get more users. You may disagree with my assessment, that's fine, I don't want to have any hard feelings, but I think your tone speaks volumes about why PostgreSQL regularly gets ignored. While it is better than MySQL in almost every metric, it has fewer users than it should. The question is why. I took a bit of time and effort to explain why I think this is so, outline a number of steps that may help. If getting more users is something that "we" want to do. Then "we" need to think about what it is "we" need to do. "We" need to understand that "we" need to do things we may not feel like doing for success. I may be completely wrong in every sentence I wrote, but lets discuss why I may be wrong, lets discuss what is the right way to do it, or lastly, lets decide that it isn't important to get more users, but don't just say "you can't."
On Sun, Apr 25, 2004 at 05:15:19PM -0400, pgsql@mohawksoft.com wrote: > (5) Programming languages. We need to make a programming language standard > in PostgreSQL. plpgsql is good, but isn't someone working on a Java > language. That would be pretty slick. If there's going to be a single standard language, I strongly believe it should be plpgsql. Any other language means that you have to find something that someone else knows or is willing to learn, whereas anyone using a database already knows SQL. plpgsql is simply an extension of SQL, and is trivial for anyone who's worked with any other database procedural languages to pickup. Asking a DBA to learn java or perl or PHP is asking a lot. If anything I'd like to see more features brought into plpgsql, like packages (ala Oracle). -- Jim C. Nasby, Database Consultant jim@nasby.net Member: Triangle Fraternity, Sports Car Club of America Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
> When all is said and done, I think the PostgreSQL project lacks a "Product > Management" group which steers the public perception and defines > usability. This is something *all* other systems have, including MySQL. Well, NO, not a chance. As one of the de-facto heads of our Advocacy group, let me say "you've got to be kidding." MySQL is a private closed-shop software manufacturer who uses the GPL as one of their methods of distribution. They are not a "real" open source project -- they are a private, commercial, for-profit software company. We are not. We are a open, 100% voluntary community of contributing developers and support volunteers. Nobody is going to take orders from a "Product Manager", that's a position for paid software products departments. It would be horribly inappropriate for PostgreSQL, and would destroy everything that has made us successful to date. You can't give orders to volunteers. You're statement that "all other systems" have a Product Manager is also wildly inaccurate. I think you're thinking of MySQL and Mozilla only. Heck, even OpenOffice.org doesn't have a Product Manager, and that is a Sun-sponsored project. Let alone, say, emacs. Or Linux. -- Josh Berkus Aglio Database Solutions San Francisco
Hi, Mark, Yes, I've seen your e-mails around. You should use a sig, though, they're easy to create. > I think I am talking about something different. In a company, the core > team would be the CTO. I think some entity, one or more people, needs to > define the product. Typically this is marketing and product management. But, as Peter reminds me all the time, we're not a company. ;-) > The why is that there is no real entity doing so. > > > 2) what this person would be doing that's not already covered by existing > > groups; > > All the groups, with the exception of advocacy, are "here's what we are > building" and "here's a bug" groups. There is planning on hackers, but it > is almost purely technical. Marketing features do no often get a > reasonable hearing. That's not an argument for not using existing apparatus. What you've persuaded me is that you should: a) join the Advocacy group; b) galvanize people around developing a coherent marketing plan; c) Lead a crew of volunteers and follow through on that process until the plan is ready for comments by Core and Hackers, d) stick around for the arguments and revisions That's what we *need*. We don't need a volunteer with a title who might or might not do any of the above. I'm particulary struck by the fact that you chose to inaugurate this discussion on Hackers, instead of Advocacy where it would have been more appropriate and where more of the *existing* marketing volunteers would have participated. At this point, I'd have to forward the whole thing to transfer it ... > I think that a talented manager could make the case for certain features. So? So could any community member with a good grasp of database engineering and an ability to write persuasive e-mails. > > 4) who this person would be. > We recrute like a company does. Um, and pay them with what? Cowrie shells? -- -Josh BerkusAglio Database SolutionsSan Francisco
pgsql@mohawksoft.com wrote: > If we want to make PostgreSQL a wildly popular product, there will be > some pain. There should be a "Product Management" group. The > leader(s) of this group should be chosen carefully, as he (they) must > be free to define what PostgreSQL is. They must have a good feel for > product development and understanding of the underlying technology, > but not be so techie that we don't address the issues intended. They > must be able to rally the troops and direct development efforts. > Lastly, he (they) must have the confidence of the core hackers, as it > is likely that there will be disagreements with the direction of > PostgreSQL, and it wouldn't work if "Product Management" couldn't > actually manage what the product was because nobody listened. I agree with this, more or less. The lack of leadership that coordinates all activities actively is really missing. Unfortunately, I believe we are already in a state of fragmentation where setting up something like this is no longer possible. What the end user sees as a PostgreSQL system is brought to them by nearly a dozen different groups nowadays. And the server group can no longer count on having a stronger position to pull them all together. The only option to achieve what you want soon is to market your own product.
> Hey, > > First of all, who is this? I don't recognize the e-mail, and you haven't > been signing any of your posts. I've been posting on hackers on and off for a few years. My name is Mark. > >> true, others, however, are very welcoming to direction. > > AFAIK, this includes none of our major code contributors. So all you're > really talking about is manipulating the TODO list. You can't tell > programmers what to code unless you're paying them. Yes and no. People can and do what's needed when it is clearly articulated. What is lacking is a clear direction WRT marketing. > >> It depends in the >> individual. Lastly, Bruce, Tom, Peter, and others are very didicated to >> PostgreSQL. If a real case can be made for a feature, I'm sure they are >> reasonable enough to see that and grudgingly implement it. Someone, >> however, has to keep an eye on that ball. > > Yes, but they don't need a title to do so. Nor is there any reason for > this > to be one person. In fact, you've just described one of the reason for > the > Core's existance -- and even the Core defers to the consensus of decision > on > this forum about which features to implement and how. I think I am talking about something different. In a company, the core team would be the CTO. I think some entity, one or more people, needs to define the product. Typically this is marketing and product management. > > Now, if you're arguing that we could use a more cohesive, readable > roadmap? > Sure! Want to prepare one? I can even help you find out what's under > development and what's not likely any time soon. Absolutely, but it would be meaningless if no body listens. > >> Linux has Linus, he has a very good eye in the market forces. > > Uh-huh. So? That still doesn't make him a "product manager". Maybe I've overstated my case, by management I mean the small 'm' not the big 'M' > >> OpenOffice is very much >> managed by Sun. > > I used to be a Project Lead for OpenOffice.org. Very cool. It is a great project/product. > I think the amount of > consensus and compromise, and the extent to which the Community Council > and > the Project Leads govern the project, would surprise you. No it wouldn't. > > Overall, I've not seen you present any coherent arguments as to: > 1) why we need a new person with a title for marketing stuff; The why is that there is no real entity doing so. > 2) what this person would be doing that's not already covered by existing > groups; All the groups, with the exception of advocacy, are "here's what we are building" and "here's a bug" groups. There is planning on hackers, but it is almost purely technical. Marketing features do no often get a reasonable hearing. > 3) how this person would be able to accomplish their "job"; I think that a talented manager could make the case for certain features. > 4) who this person would be. We recrute like a company does. > > As far as I'm concerned, we need use titles here only if it lends the > entitled > some kind of authority with the outside world that helps them on their > volunteer projects (Robert Bernier, "Business Intelligence Analyst", is a > good example of a good use of titles -- that one convinces companies that > he > approaches about case studies that he's for real). Titles are not at all > useful *inside* the community, we don't need them. I'm not trying to change the dynamic significantly, but I think, again if increasing usership is important, that some market driven lessons need to be learned.
Hey, First of all, who is this? I don't recognize the e-mail, and you haven't been signing any of your posts. > true, others, however, are very welcoming to direction. AFAIK, this includes none of our major code contributors. So all you're really talking about is manipulating the TODO list. You can't tell programmers what to code unless you're paying them. > It depends in the > individual. Lastly, Bruce, Tom, Peter, and others are very didicated to > PostgreSQL. If a real case can be made for a feature, I'm sure they are > reasonable enough to see that and grudgingly implement it. Someone, > however, has to keep an eye on that ball. Yes, but they don't need a title to do so. Nor is there any reason for this to be one person. In fact, you've just described one of the reason for the Core's existance -- and even the Core defers to the consensus of decision on this forum about which features to implement and how. Now, if you're arguing that we could use a more cohesive, readable roadmap? Sure! Want to prepare one? I can even help you find out what's under development and what's not likely any time soon. > Linux has Linus, he has a very good eye in the market forces. Uh-huh. So? That still doesn't make him a "product manager". > OpenOffice is very much > managed by Sun. I used to be a Project Lead for OpenOffice.org. I think the amount of consensus and compromise, and the extent to which the Community Council and the Project Leads govern the project, would surprise you. Overall, I've not seen you present any coherent arguments as to: 1) why we need a new person with a title for marketing stuff; 2) what this person would be doing that's not already covered by existing groups; 3) how this person would be able to accomplish their "job"; and 4) who this person would be. As far as I'm concerned, we need use titles here only if it lends the entitled some kind of authority with the outside world that helps them on their volunteer projects (Robert Bernier, "Business Intelligence Analyst", is a good example of a good use of titles -- that one convinces companies that he approaches about case studies that he's for real). Titles are not at all useful *inside* the community, we don't need them. -- -Josh BerkusAglio Database SolutionsSan Francisco
Just a reflection from someone who has not been following PostgreSQL that long... I think you provide excellent leadership and keep a firm grip on the core PostgreSQL server. Moving stuff out to Gborg and the discussion regarding contrib tells me that you want to keep it that way. As I'm a firm beliver in separation of concern and modularization, I really like that move. The server group must concentrate on the server. PosgreSQL is much more than just a server though. Something can be done that would bring order to the current chaos and make the fragementation a positive thing. What I think is needed is an architecture that goes beyond the server. An architecture endorsed by the PostgreSQL. It would of course include the semantics needed to create and link a plugin but it wouldn't stop there. A very important feature would be packaging and deployment (installers etc.). Another would be administration. The architecture I have in mind *must* be endorsed and controlled by PostgreSQL. It cannot be delivered by a freestanding group. Still, it's not core server stuff. This is the means by which PostgreSQL would (re)gain leadership of the whole thing. You don't need managers, you need a broader component architecure. My perception is that you need to somehow fork your efforts and look beyond the core server horizon. A don't think it's too late. I'm convinced that everyone that creates products that integrates with PostgreSQL would be more than happy to comply (and make additions to) a common architecture if it would help PostgreSQL to get a wider acceptance. In short, You have a great leverage. It's just a matter of using it the right way. Kind regards, Thomas Hallgren "Peter Eisentraut" <peter_e@gmx.net> wrote in message news:200404262146.54078.peter_e@gmx.net... > pgsql@mohawksoft.com wrote: > > If we want to make PostgreSQL a wildly popular product, there will be > > some pain. There should be a "Product Management" group. The > > leader(s) of this group should be chosen carefully, as he (they) must > > be free to define what PostgreSQL is. They must have a good feel for > > product development and understanding of the underlying technology, > > but not be so techie that we don't address the issues intended. They > > must be able to rally the troops and direct development efforts. > > Lastly, he (they) must have the confidence of the core hackers, as it > > is likely that there will be disagreements with the direction of > > PostgreSQL, and it wouldn't work if "Product Management" couldn't > > actually manage what the product was because nobody listened. > > I agree with this, more or less. The lack of leadership that > coordinates all activities actively is really missing. Unfortunately, > I believe we are already in a state of fragmentation where setting up > something like this is no longer possible. What the end user sees as a > PostgreSQL system is brought to them by nearly a dozen different groups > nowadays. And the server group can no longer count on having a > stronger position to pull them all together. The only option to > achieve what you want soon is to market your own product. > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >
pgsql@mohawksoft.com wrote: > (5) Programming languages. We need to make a programming language standard > in PostgreSQL. plpgsql is good, but isn't someone working on a Java > language. That would be pretty slick. IMHO SQL/PSM would be the obvious choice for the standard procedural language. Not only because it is part of the SQL standard (ISO/IEC 9075-4:2003), but also because it is reasonably intuitive and it is the same as what is implemented in DB2 (and in MySQL 5 due sometime not so soon). The only problem is that there is no PostgreSQL implementation. Jochem -- I don't get it immigrants don't work and steal our jobs - Loesje
On Mon, 26 Apr 2004, Josh Berkus wrote: > > I think that a talented manager could make the case for certain features. > > So? So could any community member with a good grasp of database engineering > and an ability to write persuasive e-mails. I'd like to inject here that I was the one who started the whole argument over date style enforcement about a year ago. It was a bit of a slog at first, but I felt my input was good, and the cause was just :-). Because of that discussion, PostgreSQL accpeting dates like 2004-31-03 and turning them into 2004-03-31 on the fly stopped. as did postgresql accepting a date like 03/31/2004 and turning it into 31/03/2004 when it was set to accept Euro style dates. I am not a PostgreSQL hacker, just a user. My input made the difference. No title needed. What PostgreSQL needs more of is caring users who can spot bugs / misbehaviours, make a decent argument about it, and maybe even a patch or two. We're way more short on indians than chiefs in my opinion.
On Tue, 27 Apr 2004, Jochem van Dieten wrote: > pgsql@mohawksoft.com wrote: > > (5) Programming languages. We need to make a programming language standard > > in PostgreSQL. plpgsql is good, but isn't someone working on a Java > > language. That would be pretty slick. > > IMHO SQL/PSM would be the obvious choice for the standard > procedural language. Not only because it is part of the SQL > standard (ISO/IEC 9075-4:2003), but also because it is reasonably > intuitive and it is the same as what is implemented in DB2 (and > in MySQL 5 due sometime not so soon). > The only problem is that there is no PostgreSQL implementation. While I can see heading in that direction, the lack of an implementation makes this suggestion impractical. It will take time not just to implement it, but to test it and debug it, and for it to reach "maturity." PL/pgsql is mature and tested, has a great deal of code already written for it, and has reached maturity. I'd say including it by default represents little or no security risk, and increases the value, out of the box, of postgresql for most folks while costing very little in terms of wasted disk space etc...
On Mon, Apr 26, 2004 at 02:31:27PM -0400, pgsql@mohawksoft.com wrote: > > On Sun, Apr 25, 2004 at 05:15:19PM -0400, pgsql@mohawksoft.com wrote: > >> (5) Programming languages. We need to make a programming language > >> standard > >> in PostgreSQL. plpgsql is good, but isn't someone working on a Java > >> language. That would be pretty slick. > > > > If there's going to be a single standard language, I strongly believe it > > should be plpgsql. Any other language means that you have to find > > something that someone else knows or is willing to learn, whereas anyone > > using a database already knows SQL. plpgsql is simply an extension of > > SQL, and is trivial for anyone who's worked with any other database > > procedural languages to pickup. Asking a DBA to learn java or perl or > > PHP is asking a lot. > > > > If anything I'd like to see more features brought into plpgsql, like > > packages (ala Oracle). > > Sorry, by standard, I meant installed by default, not to the exclusion of > all else. I would still argue that if any language should be installed by default it should be plpgsql and not java. As I mentioned, everyone using a database already knows SQL; not nearly as many know java. -- Jim C. Nasby, Database Consultant jim@nasby.net Member: Triangle Fraternity, Sports Car Club of America Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
I'm a great fan of Java. Still, I firmly believe that pgsql should be the language of choice as the one included by default. I think many users consider the ability to write functions and triggers using SQL intermixed with the DDL statements (create function etc.) as the only natural way of doing it. All other languages implies either mixing languages in the same file or splitting declaration and implementation into separate files. Java is excellent when you want to extend the language beyond what's possible using SQL. Examples might include soundex or image recognition algorithms. XML is another area where server side Java might play a significant role. But that's all beyond core server functionality. If anything, I'd rather see the JDBC and ODBC drivers reinstated in the release. More than 56% of the PostgreSQL users (according to the poll) uses JDBC today. ODBC is merely 18% but that might change significantly when the native Win32 port is released. I might have missed something altogether here, my apologies if that's the case, but looking at the coming 7.5 release, 75% of the users will be forced to download stuff from more than one location just to get their basic stuff running. Kind regards, Thomas Hallgren ""scott.marlowe"" <scott.marlowe@ihs.com> wrote in message news:Pine.LNX.4.33.0404271149070.5967-100000@css120.ihs.com... > On Tue, 27 Apr 2004, Jochem van Dieten wrote: > > > pgsql@mohawksoft.com wrote: > > > (5) Programming languages. We need to make a programming language standard > > > in PostgreSQL. plpgsql is good, but isn't someone working on a Java > > > language. That would be pretty slick. > > > > IMHO SQL/PSM would be the obvious choice for the standard > > procedural language. Not only because it is part of the SQL > > standard (ISO/IEC 9075-4:2003), but also because it is reasonably > > intuitive and it is the same as what is implemented in DB2 (and > > in MySQL 5 due sometime not so soon). > > The only problem is that there is no PostgreSQL implementation. > > While I can see heading in that direction, the lack of an implementation > makes this suggestion impractical. It will take time not just to > implement it, but to test it and debug it, and for it to reach "maturity." > > PL/pgsql is mature and tested, has a great deal of code already written > for it, and has reached maturity. I'd say including it by default > represents little or no security risk, and increases the value, out of the > box, of postgresql for most folks while costing very little in terms of > wasted disk space etc... > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >
Jim C. Nasby wrote: > >I would still argue that if any language should be installed by default >it should be plpgsql and not java. As I mentioned, everyone using a >database already knows SQL; not nearly as many know java. > > I know both. :-). Seriously - I'd like to raise my voice in favor of installing plpgsql in template1 by default. I haven't heard any good reason not to (nor even a bad reason). cheers andrew
>> >> > > I know both. :-). > > Seriously - I'd like to raise my voice in favor of installing plpgsql in > template1 by default. I haven't heard any good reason not to (nor even a > bad reason). > If we install plPGSQL by default, we should install any other pl language that was configured at runtime by default as well. This includes plPerl, plTCL, and plPython. Of course only if they were compiled in, but sense they are a part of the core distribution we shouldn't favor one over the other. Personally, plpgSQL is only useful to those who are coming from Oracle. People are more likely to be comfortable with plPython or plPerl than plpgSQL. Sincerely, Joshua D. Drake > cheers > > andrew > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match
On Tue, Apr 27, 2004 at 01:14:08PM -0700, Joshua D. Drake wrote: > If we install plPGSQL by default, we should install any other pl > language that was configured at runtime by default as well. This > includes plPerl, plTCL, and plPython. That certainly makes sense. > Of course only if they were compiled in, but sense they are a part of > the core distribution we shouldn't favor one over the other. > > Personally, plpgSQL is only useful to those who are coming from Oracle. > People are more likely to be comfortable with plPython or plPerl than > plpgSQL. I'll beg to differ. :) I started using PostgreSQL well over a year before Oracle. plpgSQL is SQL based; that's the key difference. I can't back this up, but I'd bet that the majority of professional DBAs would be far more comfortable in plpgSQL than in plPython or plPerl because they deal with SQL day in and day out, while they probably only use other languages for scripting (java being one possible exception). Ultimately I think it's fine that PostgreSQL doesn't favor any of the languages, but I think plpgSQL would be the only logical one to favor if that was going to be the case. But then again, I'm a professional DBA; I suspect someone who is more of a coder than a DBA might disagree. -- Jim C. Nasby, Database Consultant jim@nasby.net Member: Triangle Fraternity, Sports Car Club of America Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
Joshua D. Drake wrote: > > If we install plPGSQL by default, we should install any other pl > language that was configured at runtime by default as well. This > includes plPerl, plTCL, and plPython. > > Of course only if they were compiled in, but sense they are a part of > the core distribution we shouldn't favor one over the other. > > Personally, plpgSQL is only useful to those who are coming from Oracle. > People are more likely to be comfortable with plPython or plPerl than > plpgSQL. > Joshua - as you know I'm a perl fan. But plpgsql is special, for a number of reasons, not least that it doesn't require any extra libraries, and should be installable on every postgresql system. I know people hate playing favourites, but you can take that too far. cheers andrew
> If anything, I'd rather see the JDBC and ODBC drivers reinstated in the > release. More than 56% of the PostgreSQL users (according to the poll) uses > JDBC today. ODBC is merely 18% but that might change significantly when the > native Win32 port is released. I might have missed something altogether > here, my apologies if that's the case, but looking at the coming 7.5 > release, 75% of the users will be forced to download stuff from more than > one location just to get their basic stuff running. Note that MySQL doesn't bundle them, but they are CLEARLY available for download on their site on all places where MySQL itself is available for download. Chris
Joshua D. Drake wrote:
>> I know both. :-).
>>
>> Seriously - I'd like to raise my voice in favor of installing plpgsql
>> in template1 by default. I haven't heard any good reason not to (nor
>> even a bad reason).
>>
>
> If we install plPGSQL by default, we should install any other pl
> language that was configured at runtime by default as well. This
> includes plPerl, plTCL, and plPython.
>
> Of course only if they were compiled in, but sense they are a part of
> the core distribution we shouldn't favor one over the other.
>
> Personally, plpgSQL is only useful to those who are coming from Oracle.
> People are more likely to be comfortable with plPython or plPerl than
> plpgSQL.
I disagree. I know python and perl and I have never touched Oracle, but
I find plpgsql to be more useful than the others. Mainly because
(1) It is strongly typed, has all the same types as postgresql itself,
consistent support for NULLS, etc.
(2) Upon a casual read of the docs I couldn't figure out how to read any
values from the database other than what was passed into the
pl{perl|python|php} function. I.e., how do you run a select? What client
libraries do you use? Maybe the others just need better docs.
Paul Tillotson
jim@nasby.net ("Jim C. Nasby") writes:
> I would still argue that if any language should be installed by
> default it should be plpgsql and not java. As I mentioned, everyone
> using a database already knows SQL; not nearly as many know java.
A vital factor is indeed that pl/pgsql does not require require
importing extra APIs to access the database.
--
(format nil "~S@~S" "cbbrowne" "ntlug.org")
http://www3.sympatico.ca/cbbrowne/sgml.html
Sleep is a poor subsititute for caffeine. -Pat Dughi
Centuries ago, Nostradamus foresaw when jd@commandprompt.com ("Joshua D. Drake") would write:
> Personally, plpgSQL is only useful to those who are coming from
> Oracle. People are more likely to be comfortable with plPython or
> plPerl than plpgSQL.
I beg to differ.
In order to use pl/Python or pl/Perl to manipulate data in the
database, I have to go and find an SPI module.
With pl/pgsql, all I need to do is to directly present the SQL
queries.
The flip side, of course, is that Perl and Python provide nice idioms
for fiddling with text that are much nicer than clumsy usages of
substr() in pl/pgsql.
I'd rather do complex text validation in Perl, but write code that
does "table stuff" in pl/pgsql.
That is indeed the /exact/ approach I have taken in using stored
procedures for data conversions; a mix of the both, using each to
harness its respective strengths.
--
let name="cbbrowne" and tld="cbbrowne.com" in name ^ "@" ^ tld;;
http://www3.sympatico.ca/cbbrowne/lsf.html
'Mounten' wird fuer drei Dinge benutzt: 'Aufsitzen' auf Pferde,
'einklinken' von Festplatten in Dateisysteme, und, nun, 'besteigen'
beim Sex.
Joshua D. Drake wrote: > Personally, plpgSQL is only useful to those who are coming from Oracle. > People are more likely to be comfortable with plPython or plPerl than > plpgSQL. Well that was not true for my, I started using postgres and plpgsql not because I knew Oracle ( I don't know it ). plpgsql is more close to postgres then plPython or plPerl, and after all is nearest SQL then plPtyhton or plPerl so a DBA find it more confortable then others languages. my two cents. Regards Gaetano Mendola
> > plpgsql is more close to postgres then plPython or plPerl, and after > all is nearest SQL then plPtyhton or plPerl so a DBA find it more > confortable then others languages. DBA probably... programmer? Doubtful. The majority of people that I run into that are using PostgreSQL are not DBA's. They are programmers trying to do it a better way. Providing plPerl or plPython etc... allows them to stay in a native and productive environment. Sincerely, Joshua D. Drake > > > my two cents. > > > > Regards > Gaetano Mendola > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Вложения
Joshua D. Drake wrote: >> >> plpgsql is more close to postgres then plPython or plPerl, and after >> all is nearest SQL then plPtyhton or plPerl so a DBA find it more >> confortable then others languages. > > > DBA probably... programmer? Doubtful. The majority of people that I run > into that are using PostgreSQL are not DBA's. They are programmers > trying to do it a better way. Providing plPerl or plPython etc... allows > them to stay in a native and productive environment. True, but a good DBA have to check each single store procedure and view that other programmers write, see tuning techics that programmers are not aware of ( see select max(id) from foo; optimized with a order by + limit 1 ). Regards Gaetano Mendola