Re: [GENERAL] Humor me: Postgresql vs. MySql (esp. licensing)
Randal L. Schwartz [EMAIL PROTECTED] Wrote: The biggest advantage MySQL still has over PostgreSQL is the same advantage Microsoft has over Unix - entrenchment, both in software and mindshare. There is another thing too-- MySQL manages connection permissions entirely within the RDBMS, while PostgreSQL relies on the pg_hba.conf. This makes managing a database server in a shared hosting environment a bit harder. While I appreciate the PostgreSQL way of doing things, I realize that it is a bit harder to make work for the average web hosting provider. I am currently looking at the possibility of building a solution, but no one has expressed interest, so I am not sure. FWIW, here is what I have in mind: A PostgreSQL database with hooks into the pg_hba.conf so that new user accounts can be created, along with databases, etc. and all permissions properly managed. Whether the pg_hba should be parsed and treated as an external table using PL/PerlU or whether it should be recreated on demand is a question I am still considering (pro's and cons of doing things either way). Obviously this would not have a wide audience, but it would go a LONG way towards challenging both MS SQL and MySQL in the web hosting space. Another opportunity here is helping port legacy MySQL applications to PostgreSQL, ensuring demand for the RDBMS continues to grow. Best Wishes, Chris Travers ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] PostgreSQL Advocacy, Thoughts and Comments
Tony [EMAIL PROTECTED] Wrote: Now many consultant/developer/sys-admins like myself are going to client site on a contract (this is especially true in the UK, I can't speak for anywhere else) and finding complex stocktrading systems, inventory systems, CRM systems, and others, all written in PHP backed by MySQL. I started the CRM system I am developing on MySQL before realizing it was the wrong choice. Part of it is simple because people have heard of the software and don't have the time/stamina/patience to do proper research into the benefits of alternatives. There is also a learning curve when going from MySQL to a more standards-compliant RDBMS like PostgreSQL. Heck, I found that going from PostgreSQL to Firebird give me headaches :-P And these RDBMS's have most of the same features! Whether this is right or wrong, good choice or bad choice is not what I'm interested in debating. The point is that when these systems where architected, the developers used MySQL not because they were dumb, but because many of them develop awesome code and can get around most problems in the code, with a little ingenuity. Many simply do not have the insight into the potential benefits of *proper* RDBMS can offer. I would actually venture to say that many of them are using the RDBMS as a sort of object-persistance store, and not really trying to use the *relational* features of the software. They might as well be using Berkeley DB 4. I know that is how I started with MySQL. What most of these programmers do not understand is that an RDBMS is not simply a search-engine for stored persistant objects, but is actually a fully-featured information storage management system. With the right features, this information can be stored, queried, presented in another form, etc. all while ensuring that the stored information is EXACTLY what was intended. The tasks that the RDBMS handles include data storage, integrity enforcement, and data presentation. Most MySQL programmers only use it for data storage. Sadly, this is about all MySQL is good for, and hence the barrier to learning how to USE a REAL RDBMS are a bit higher because of the prevalence of the likes of MySQL and MS Access. The second scenario, is with admin systems, written by people like myself for companies, whether they be simple or complex systems, that are intended as a temporary work around to an immediate problem. In a very short space of time the stop-gap application you had written to sort out the immediate problem quickly becomes a core business application (I recently returned to a site after not being there for two years and the temporary address book/ email system that I knocked up in an afternoon was not only still being used, but now relied upon heavily). But again, if you start with the right tools, it is easier to modify later to adapt to changing needs. I think that this is one of the messages we should be presenting. With updateable views, different applications can even have access to different presentations of the data. So on to my point, MySQL guys will happily say Hey, we're not saying that the features MySQL is missing aren't important, and we're working towards them, but in the meantime these issues can be worked around like this. and happily play the whole thing down. Many LAMP developers aren't aware of the benefits of stored procedures, of triggers and other good stuff. Like myself, if they were aware how much easier life could be if these things were accessible to them, they'd probably be converts too. Agreed completely. Now we just have to sell the PostgreSQL solution. Here is what the MySQL people will say (and we need good evidence to counter): 1: MySQL is faster. 2: MySQL has more community support. 3: MySQL has replication as part of its core distribution. MySQL's replication is better tested... There is not enough emphasis put on the basic importance of these functions in PG. Someone needs to standup and say Hey, look how this can simplify your programming lives until I started using Druid/Postgres, I had no idea why I needed triggers or what a cascade effect did, or why I might want one. The basic issue is that many programmers are not taught to value information management systems, such as RDBMS's. These programmers are interested only in the data storage issues of the database, and not on how to use it to manage the information stored therein. Changing this may take a lot of effort. Also, using an RDBMS to its full extent rubs some OO programmers the wrong way because it strikes them as violating rules of OO design. Of course, then why not use an OO database? ;-) The Linux community has grown at least in part because it has educated potential users and journo's to its benefits. I believe if the PG advocacy team did the same, then it would attract many more serious LAMP developers. I agree. But it will take some time to sell, and will require some extremely
Re: [GENERAL] permission errors for set authority and schema public
CSN writes: I upgraded to 7.4 a few days ago and am getting these errors when importing dumps: permission denied to set session authority and permission denied for schema public. Not all of the dump is imported successfully. Looks like you need to restore as superuser. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] PostgreSQL Advocacy, Thoughts and Comments
Title: Re: [GENERAL] PostgreSQL Advocacy, Thoughts and Comments Comments within: Chris Travers wrote: Tony [EMAIL PROTECTED] Wrote: Now many consultant/developer/sys-admins like myself are going to client site on a contract (this is especially true in the UK, I can't speak for anywhere else) and finding complex stocktrading systems, inventory systems, CRM systems, and others, all written in PHP backed by MySQL. I started the CRM system I am developing on MySQL before realizing it was the wrong choice. Part of it is simple because people have heard of the software and don't have the time/stamina/patience to do proper research into the benefits of alternatives. There is also a learning curve when going from MySQL to a more standards-compliant RDBMS like PostgreSQL. Heck, I found that going from PostgreSQL to Firebird give me headaches :-P And these RDBMS's have most of the same features! It's the learning curve part that I'm finding difficult, not because it's a too complicated, but because I can't find a good source of information to learn from. I'm sure I'll get flamed for this, but I seem to be unable to find information on proper design principle, including where and when to use triggers, stored procs, etc, etc, that isn't 20 years old already. In the liquid world of IT, I find it worrying (perhaps incorrectly) learning from a book written 14 years ago. Whether this is right or wrong, good choice or bad choice is not what I'm interested in debating. The point is that when these systems where architected, the developers used MySQL not because they were dumb, but because many of them develop awesome code and can get around most problems in the code, with a little ingenuity. Many simply do not have the insight into the potential benefits of *proper* RDBMS can offer. I would actually venture to say that many of them are using the RDBMS as a sort of object-persistance store, and not really trying to use the *relational* features of the software. They might as well be using Berkeley DB 4. I know that is how I started with MySQL. Agreed... What most of these programmers do not understand is that an RDBMS is not simply a search-engine for stored persistant objects, but is actually a fully-featured information storage management system. With the right features, this information can be stored, queried, presented in another form, etc. all while ensuring that the stored information is EXACTLY what was intended. The tasks that the RDBMS handles include data storage, integrity enforcement, and data presentation. Most MySQL programmers only use it for data storage. Sadly, this is about all MySQL is good for, and hence the barrier to learning how to USE a REAL RDBMS are a bit higher because of the prevalence of the likes of MySQL and MS Access. Indeed, and I believe that the lack of education with regards to this (or even available information presented at the right level) perpetuates the issue, along with the mis-information put forward by MySQL that these aspects aren't really all that important anyway. The second scenario, is with admin systems, written by people like myself for companies, whether they be simple or complex systems, that are intended as a temporary work around to an immediate problem. In a very short space of time the stop-gap application you had written to sort out the immediate problem quickly becomes a core business application (I recently returned to a site after not being there for two years and the temporary address book/ email system that I knocked up in an afternoon was not only still being used, but now relied upon heavily). But again, if you start with the right tools, it is easier to modify later to adapt to changing needs. I think that this is one of the messages we should be presenting. With updateable views, different applications can even have access to different presentations of the data. So on to my point, MySQL guys will happily say "Hey, we're not saying that the features MySQL is missing aren't important, and we're working towards them, but in the meantime these issues can be worked around like this." and happily play the whole thing down. Many LAMP developers aren't aware of the benefits of stored procedures, of triggers and other good stuff. Like myself, if they were aware how much easier life could be if these things were accessible to them, they'd probably be converts too. Agreed completely. Now we just have to sell the PostgreSQL solution. Here is what the MySQL people will say (and we need good evidence to counter): 1: MySQL is faster. 2: MySQL has more community support. 3: MySQL has replication as part of its core distribution. MySQL's replication is better tested... 1. Let's do apples to apples, NOT apples to Oranges as has been done many times in the past. It would be far more useful IMHO to put forward a "real world"
Re: Triggers, Stored Procedures, PHP. was: Re: [GENERAL] PostgreSQL Advocacy, Thoughts and Comments
On 29/11/2003 16:24 Jason Tesser wrote: [snip] A programmer that doesn't document stuff needs to find a new job :-) Agreed. So you're replaced him and inherited a documentation-free application. How many favours has he done you by squirrelling away section of business logic in the database? This is more of an issue with management. Anyone who does database apps for on any kind of a large scale will tell you that views, triggers, etc.. are essential. I am currently in teh process of writing a complete solution for the college I develop for. Finance, accounting, pos, registration, student tracking etc... I've worked on stuff for some of the largest companies in the world if that counts. Mind you, I've been in the business 24 years (18 of those as an independent consultant) so maybe I'm just a newbie :) For your accounting, take a look at SQL-Ledger (www.sql-ledger.org). It might save you months of effort. You might not have understood me or I am not understanding you. It feels like we're 2 people divided by a common language... -- Paul Thomas +--+-+ | Thomas Micro Systems Limited | Software Solutions for the Smaller Business | | Computer Consultants | http://www.thomas-micro-systems-ltd.co.uk | +--+-+ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Was: Triggers, Stored Procedures, PHP
On Mon, Dec 01, 2003 at 09:38:06AM +1100, Alex Satrapa wrote: create or replace function get_transactions (INTEGER) returns set of record as ' DECLARE cust_id ALIAS FOR $1; BEGIN for r in select ... from ... loop return next r; end loop; return; END ' language 'plpgsql'; But I would certainly love to have parameterised views :) Me too. I've created many functions to extract data that are joined to other functions. All in all the result is not as optimal as it could be, because the optimizer can not poke into the functions, and the estimates about functions are only guesses. If one could use parametrized views instead of functions the whole mess would probably be more optimal. Maybe there's a TODO here? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Ninguna manada de bestias tiene una voz tan horrible como la humana (Orual) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Was: Triggers, Stored Procedures, PHP
Alvaro Herrera wrote: Me too. I've created many functions to extract data that are joined to other functions. All in all the result is not as optimal as it could be, because the optimizer can not poke into the functions, and the estimates about functions are only guesses. If one could use parametrized views instead of functions the whole mess would probably be more optimal. How is a parameterized view any different than a set returning SQL function? In either case, you've got the same work to do to teach the optimizer how to understand it, no? Seems like the todo is just that, teach the optimizer how to do better with set-returning SQL functions. Joe ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
