Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Robert Treat wrote: On Tuesday 27 April 2004 15:12, Alvaro Herrera wrote: You know, that's kind of the point of all things related to MySQL. It's better than nothing. PostgreSQL doesn't do things because it's better than nothing. snip (Same as how MySQL guesses the result of a modulo operation, and gets it wrong. They don't care and you can read that on the manual. In Postgres, this is a bug.) Hey Alvaro, are you familiar with worse is better philosphy in software development and how that leads to adoption rates? It basically states that simplicity is the ultimate design goal over correctness, consitency, and completness. Because of this more people are able to quickly adopt a technology, which allows the incorrectness/inconsistency/incompletness to be address by new comers and gradually bring the software up to higher standards. I was reading some blogs the other day that applied this to PHP's adoption rate over Java and .net, but your comment made me think this really applies to my$ql and postgresql as well. check out http://www.sitepoint.com/forums/showpost.php?p=1121502postcount=2 for a bit more. Interesting analysis. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Tuesday 27 April 2004 15:12, Alvaro Herrera wrote:
You know, that's kind of the point of all things related to MySQL.
It's better than nothing. PostgreSQL doesn't do things because it's
better than nothing. snip
(Same as how MySQL guesses the result of a modulo operation, and gets it
wrong. They don't care and you can read that on the manual. In
Postgres, this is a bug.)
Hey Alvaro,
are you familiar with worse is better philosphy in software development and
how that leads to adoption rates? It basically states that simplicity is the
ultimate design goal over correctness, consitency, and completness. Because
of this more people are able to quickly adopt a technology, which allows the
incorrectness/inconsistency/incompletness to be address by new comers and
gradually bring the software up to higher standards. I was reading some
blogs the other day that applied this to PHP's adoption rate over Java and
.net, but your comment made me think this really applies to my$ql and
postgresql as well. check out
http://www.sitepoint.com/forums/showpost.php?p=1121502postcount=2 for a bit
more.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Tue, May 04, 2004 at 03:06:53PM -0400, Robert Treat wrote: On Tuesday 27 April 2004 15:12, Alvaro Herrera wrote: You know, that's kind of the point of all things related to MySQL. It's better than nothing. PostgreSQL doesn't do things because it's better than nothing. snip (Same as how MySQL guesses the result of a modulo operation, and gets it wrong. They don't care and you can read that on the manual. In Postgres, this is a bug.) Hey Alvaro, are you familiar with worse is better philosphy in software development and how that leads to adoption rates? Yeah, I've read about it. I'm not sure which side of the do I sit on, though. The wikipedia entry may be a good read: http://en.wikipedia.org/wiki/Worse_is_better Note that it puts correctness and consistency after simplicity, but this not means that they are completely put away. I think SQL (as in SQL standard) is not modelled after this idea: SQL tries to be complete rather than simple. I may be wrong though. Certainly MySQL does away with completeness and tries to achieve simplicity, while the opposite could be said of Postgres. Fortunately, Postgres has apparently caught up with developer mass, so it may yet be able to win against MySQL ... -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Linux transformó mi computadora, de una `máquina para hacer cosas', en un aparato realmente entretenido, sobre el cual cada día aprendo algo nuevo (Jaime Salinas) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Robert Treat [EMAIL PROTECTED] writes: On Tuesday 27 April 2004 15:12, Alvaro Herrera wrote: You know, that's kind of the point of all things related to MySQL. It's better than nothing. PostgreSQL doesn't do things because it's better than nothing. snip (Same as how MySQL guesses the result of a modulo operation, and gets it wrong. They don't care and you can read that on the manual. In Postgres, this is a bug.) Hey Alvaro, are you familiar with worse is better philosphy in software development and how that leads to adoption rates? It basically states that simplicity is the ultimate design goal over correctness, consitency, and completness. Because of this more people are able to quickly adopt a technology, which allows the incorrectness/inconsistency/incompletness to be address by new comers and gradually bring the software up to higher standards. I was reading some blogs the other day that applied this to PHP's adoption rate over Java and .net, but your comment made me think this really applies to my$ql and postgresql as well. check out http://www.sitepoint.com/forums/showpost.php?p=1121502postcount=2 for a bit more. The problem with the Worse is Better philosophy is that it almost totally overlooks price, which is arguably the most important factor in deciding which technologies get adopted. The real trick is being good enough at the lowest price. When MySQL became the de-facto web database (back in the Postgres95 and Postgres 6.X days) PostgreSQL simply wasn't good enough for most sites. PostgreSQL, in those days, was slow, buggy, and decidedly non-standard (anyone else remember PostQUEL). On the plus side I personally don't think that Free Software databases have really hit their stride yet, and I believe that when they do PostgreSQL is going to be front and center. MySQL is a pretty handy datastore, but PostgreSQL is a far more useful tool for creating complex applications. Jason ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Hi! Tim Conrad wrote: I was researching an article I wrote about a comparison between Postgres and MySQL recently (If you want, you can read the article at http://www.devx.com/dbzone/Article/20743/). I noticed some clear differences between the mysql.com website and the Postgres website. Sorry, couldn't resist: may I suggest doing the research *before* writing an article, not *after*? My favourite part of it is: MySQL uses traditional row-level locking. PostgreSQL uses something called Multi Version Concurrency Control (MVCC) by default. MVCC is a little different from row-level locking in that transactions on the database are performed on a snapshot of the data and then serialized. New versions of PostgreSQL support standard row-level locking as an option, but MVCC is the preferred method. 2) There doesn't seem to be a clear roadmap on Postgres features. When certian things are expected. There's the TODO list that Bruce maintains, but it only outlines 'near' fixes. MySQL has a nice listing of what to expect in certian future versions. I know it's not a perfect list, but it'd be nice to know when full blown replication will be included in PostgreSQL as an example. MySQL's roadmap is complete bullshit. Subselects were first promised in 4.0, which was not that far away [1] back in 1998! Well, they are in 4.1, which is still alpha in 2004. Of course, some gullible people actually believe this and compare [2] the existing and working implementations with vaporware (MySQL 5.1, anyone?). On those same lines, there doesn't seem to be anything about the improvements in the minor versions. It seems that in every release (i.e. 7.2,7.3,7.4) there are pretty significant changes, but finding a place that outlines these changes is somewhat difficult. Have you tried looking in the release notes [3]? [1] http://www.geocrawler.com/archives/3/194/1998/8/0/1061364/ [2] http://www.devx.com/dbzone/Article/20743/1763?supportItem=1 [3] http://www.postgresql.org/docs/7.4/interactive/release.html ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Alexey Borzov wrote: I realize this. I also realize that having a nicely defined roadmap would give Postgres a hands up in this category. A hands up in *what* category? In bragging? In telling your boss, I think we should use Postgresql. It's likely he's not stupid, and it's reasonable for him to say since I'm tying my own success to this software, I want to have some indication as to where this software is going to go. Something like Josh Berkus' table of features would be very nice. (I've worked with sales teams at my various former employers, and the best things you can provide them are documents (feature descriptions, competitive analyses, white papers, etc) that your customer contact can use as the basis for his own justification to buy your product. All of this can be summarized as make it easy for people to help you.) Cheers, Mark -- Mark Harrison Pixar Animation Studios ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Hi! Tim Conrad wrote: My favourite part of it is: MySQL uses traditional row-level locking. PostgreSQL uses something called Multi Version Concurrency Control (MVCC) by default. MVCC is a little different from row-level locking in that transactions on the database are performed on a snapshot of the data and then serialized. New versions of PostgreSQL support standard row-level locking as an option, but MVCC is the preferred method. Nice that you point out that incorrectly stated something. Even nicer that you don't tell me what the correct answer would be. Unfortunanatly, that's the best I could come up with with doing research with the documentation I could find on the subject. MVCC does a lot more than can be easily contained in a sentance. The problem is that in MySQL 1) MyISAM does table-level locking; 2) BDB does row-level locking; 3) InnoDB does MVCC (mostly) like PostgreSQL. PostgreSQL does support row-level locking (SELECT ... FOR UPDATE), table-level locking (LOCK TABLE ...), though this does not *replace* MVCC, as one may understand from the quotation. MySQL's roadmap is complete bullshit. Subselects were first promised in 4.0, which was not that far away [1] back in 1998! Well, they are in 4.1, which is still alpha in 2004. I realize this. I also realize that having a nicely defined roadmap would give Postgres a hands up in this category. A hands up in *what* category? In bragging? Should PostgreSQL developers write something along the lines of PostgreSQL 9i (available Really Soon Now) will also be able to make coffee? Well, as you know about coffee now, why don't you add make coffee to your comparison table, with empty space in MySQL's and commercial DBMSs' columns and in 9i in PostgreSQL's one? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Dear Tim, These are execellent proposals. My only remark would be to build a step-by-step approach. In a first stage, we could set-up a minimal web page for the Win32 port: - PostgreSQL Win32 installer (possibly translated), - translation of the web page in 40 languages, - step-by-step installation under Win32 (screenshots), - links (NLS project, documentation), ... advertise (example: http://www.pgadmin.org/pgadmin3/advocacy.php) and start monitoring downloads. With PostgreSQL Win32 version and looking at pgAdmin III statistics, reaching one million downloads every month seems a reasonable target. PostgreSQL is such a wonderful community project that there is no need to build complex marketing strategies to reach impressive goals. In a second stage, we can start building a rich web site (as you proposed) and make it live on the long run. Best regards, Jean-Michel I've been sort-of reading this thread off and on, so this may contain duplicate suggestions. I was researching an article I wrote about a comparison between Postgres and MySQL recently (If you want, you can read the article at http://www.devx.com/dbzone/Article/20743/). I noticed some clear differences between the mysql.com website and the Postgres website. 1) Since MySQL AB supports and trains for MySQL, there's loads of training information available on their website. On the other hand, I had a hard time finding training information for Postgres in general. Same goes for support. It's easier to find, but it's still somewhat convoluted, IMO. 2) There doesn't seem to be a clear roadmap on Postgres features. When certian things are expected. There's the TODO list that Bruce maintains, but it only outlines 'near' fixes. MySQL has a nice listing of what to expect in certian future versions. I know it's not a perfect list, but it'd be nice to know when full blown replication will be included in PostgreSQL as an example. On those same lines, there doesn't seem to be anything about the improvements in the minor versions. It seems that in every release (i.e. 7.2,7.3,7.4) there are pretty significant changes, but finding a place that outlines these changes is somewhat difficult. While being somewhat nit-picky on this, it'd also be helpful if someone wasn't completely database literate could understand some of the changes. Who needs transactions, anyways? :) 3) There's the issues of 'advanced database features' in general. Many MySQL applications perform much of their logic in the application level, instead of the database level. They do this because there aren't things like triggers or stored procedures in MySQL. As the saying goes, 'if mohammad won't go to the mountain, bring the mountian to mohammad'. Why not do some simple explainations as to why these things are good, and what they do, and how to use them in real context? 4) As other peole have noted, there's no windows build readily available for Postgres. There may be, but it's difficult to find. If someone's used to running, say, Oracle, and all they have is a windows machine to test something out on, MySQL has compiled binaries ready to go. 5) I believe that this was noted as well somewhere along the line - the other tools, like pgadmin III aren't readily available either. They're excellent tools, and they should be quick to find on the postgres website. 6) Bug tracking. I haven't really looked into how MySQL handles this, but when learning about Postgres, I discovered that the whole development model seemed kind of 'closed', and people on the mailing lists would find bugs repeatedly. Something like Bugzilla would be very helpful in this respect. I've been kind of out of the loop for the past 6 months in this area, so it may have changed since then. 7) The two Postgres books are available online for anyone to read and download. They're there, but, to me, you have to notice them on the sidebar to go to them. They're extremely helpful, and they should be pointed out more. Most of these suggestions aren't really anything to do with the database itself. It's simply a re-organization of some of the information that's already available. As others have mentioned, 'it's about the PR'. Just my $.02 worth. Tim ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
I've been sort-of reading this thread off and on, so this may contain duplicate suggestions. I was researching an article I wrote about a comparison between Postgres and MySQL recently (If you want, you can read the article at http://www.devx.com/dbzone/Article/20743/). I noticed some clear differences between the mysql.com website and the Postgres website. 1) Since MySQL AB supports and trains for MySQL, there's loads of training information available on their website. On the other hand, I had a hard time finding training information for Postgres in general. Same goes for support. It's easier to find, but it's still somewhat convoluted, IMO. 2) There doesn't seem to be a clear roadmap on Postgres features. When certian things are expected. There's the TODO list that Bruce maintains, but it only outlines 'near' fixes. MySQL has a nice listing of what to expect in certian future versions. I know it's not a perfect list, but it'd be nice to know when full blown replication will be included in PostgreSQL as an example. On those same lines, there doesn't seem to be anything about the improvements in the minor versions. It seems that in every release (i.e. 7.2,7.3,7.4) there are pretty significant changes, but finding a place that outlines these changes is somewhat difficult. While being somewhat nit-picky on this, it'd also be helpful if someone wasn't completely database literate could understand some of the changes. Who needs transactions, anyways? :) 3) There's the issues of 'advanced database features' in general. Many MySQL applications perform much of their logic in the application level, instead of the database level. They do this because there aren't things like triggers or stored procedures in MySQL. As the saying goes, 'if mohammad won't go to the mountain, bring the mountian to mohammad'. Why not do some simple explainations as to why these things are good, and what they do, and how to use them in real context? 4) As other peole have noted, there's no windows build readily available for Postgres. There may be, but it's difficult to find. If someone's used to running, say, Oracle, and all they have is a windows machine to test something out on, MySQL has compiled binaries ready to go. 5) I believe that this was noted as well somewhere along the line - the other tools, like pgadmin III aren't readily available either. They're excellent tools, and they should be quick to find on the postgres website. 6) Bug tracking. I haven't really looked into how MySQL handles this, but when learning about Postgres, I discovered that the whole development model seemed kind of 'closed', and people on the mailing lists would find bugs repeatedly. Something like Bugzilla would be very helpful in this respect. I've been kind of out of the loop for the past 6 months in this area, so it may have changed since then. 7) The two Postgres books are available online for anyone to read and download. They're there, but, to me, you have to notice them on the sidebar to go to them. They're extremely helpful, and they should be pointed out more. Most of these suggestions aren't really anything to do with the database itself. It's simply a re-organization of some of the information that's already available. As others have mentioned, 'it's about the PR'. Just my $.02 worth. Tim ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Tue, 27 Apr 2004, Tim Conrad wrote: 2) There doesn't seem to be a clear roadmap on Postgres features. When certian things are expected. There's the TODO list that Bruce maintains, but it only outlines 'near' fixes. MySQL has a nice listing of what to expect in certian future versions. Not possible for us, since we have no upper management that dictates what features get added, for when ... I know it's not a perfect list, but it'd be nice to know when full blown replication will be included in PostgreSQL as an example. Never, since there is no such thing as a 'full blown replication', since there is no *one* way to do replication ... 3) There's the issues of 'advanced database features' in general. Many MySQL applications perform much of their logic in the application level, instead of the database level. They do this because there aren't things like triggers or stored procedures in MySQL. As the saying goes, 'if mohammad won't go to the mountain, bring the mountian to mohammad'. Why not do some simple explainations as to why these things are good, and what they do, and how to use them in real context? Just a matter of someone writing and submitting it ... how are your writing skills? :) 4) As other peole have noted, there's no windows build readily available for Postgres. There may be, but it's difficult to find. If someone's used to running, say, Oracle, and all they have is a windows machine to test something out on, MySQL has compiled binaries ready to go. there is no native windows currently available, but its being worked on for 7.5 ... after which, a pre-compiled binary becomes automatic ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Tue, Apr 27, 2004 at 07:55:08PM +0400, Alexey Borzov wrote: Hi! Tim Conrad wrote: I was researching an article I wrote about a comparison between Postgres and MySQL recently (If you want, you can read the article at http://www.devx.com/dbzone/Article/20743/). I noticed some clear differences between the mysql.com website and the Postgres website. Sorry, couldn't resist: may I suggest doing the research *before* writing an article, not *after*? My favourite part of it is: MySQL uses traditional row-level locking. PostgreSQL uses something called Multi Version Concurrency Control (MVCC) by default. MVCC is a little different from row-level locking in that transactions on the database are performed on a snapshot of the data and then serialized. New versions of PostgreSQL support standard row-level locking as an option, but MVCC is the preferred method. Nice that you point out that incorrectly stated something. Even nicer that you don't tell me what the correct answer would be. Unfortunanatly, that's the best I could come up with with doing research with the documentation I could find on the subject. MVCC does a lot more than can be easily contained in a sentance. 2) There doesn't seem to be a clear roadmap on Postgres features. When certian things are expected. There's the TODO list that Bruce maintains, but it only outlines 'near' fixes. MySQL has a nice listing of what to expect in certian future versions. I know it's not a perfect list, but it'd be nice to know when full blown replication will be included in PostgreSQL as an example. MySQL's roadmap is complete bullshit. Subselects were first promised in 4.0, which was not that far away [1] back in 1998! Well, they are in 4.1, which is still alpha in 2004. I realize this. I also realize that having a nicely defined roadmap would give Postgres a hands up in this category. Of course, some gullible people actually believe this and compare [2] the existing and working implementations with vaporware (MySQL 5.1, anyone?). On those same lines, there doesn't seem to be anything about the improvements in the minor versions. It seems that in every release (i.e. 7.2,7.3,7.4) there are pretty significant changes, but finding a place that outlines these changes is somewhat difficult. Have you tried looking in the release notes [3]? [1] http://www.geocrawler.com/archives/3/194/1998/8/0/1061364/ [2] http://www.devx.com/dbzone/Article/20743/1763?supportItem=1 [3] http://www.postgresql.org/docs/7.4/interactive/release.html I guess I'm an ignorant fool and I don't comprehend many of the items under the release note. I'm also looking for something I can hand my boss and say ' this is why we should use postgres instead of oracle'. Tim ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Tue, Apr 27, 2004 at 12:58:59PM -0300, Marc G. Fournier wrote: On Tue, 27 Apr 2004, Tim Conrad wrote: 2) There doesn't seem to be a clear roadmap on Postgres features. When certian things are expected. There's the TODO list that Bruce maintains, but it only outlines 'near' fixes. MySQL has a nice listing of what to expect in certian future versions. Not possible for us, since we have no upper management that dictates what features get added, for when ... Not entirely true. I've read enough on the lists to see Bruce or others saying 'x feature isn't expected until version y.z'. Heck, to me, something that says 'we're hoping for feature x in version y.z', but it's not an exact science. See the MySQL releases as an example :) I know it's not a perfect list, but it'd be nice to know when full blown replication will be included in PostgreSQL as an example. Never, since there is no such thing as a 'full blown replication', since there is no *one* way to do replication ... It was puretly there for example purposes... 3) There's the issues of 'advanced database features' in general. Many MySQL applications perform much of their logic in the application level, instead of the database level. They do this because there aren't things like triggers or stored procedures in MySQL. As the saying goes, 'if mohammad won't go to the mountain, bring the mountian to mohammad'. Why not do some simple explainations as to why these things are good, and what they do, and how to use them in real context? Just a matter of someone writing and submitting it ... how are your writing skills? :) 4) As other peole have noted, there's no windows build readily available for Postgres. There may be, but it's difficult to find. If someone's used to running, say, Oracle, and all they have is a windows machine to test something out on, MySQL has compiled binaries ready to go. there is no native windows currently available, but its being worked on for 7.5 ... after which, a pre-compiled binary becomes automatic ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Tim Conrad wrote: Of course, some gullible people actually believe this and compare [2] the existing and working implementations with vaporware (MySQL 5.1, anyone?). On those same lines, there doesn't seem to be anything about the improvements in the minor versions. It seems that in every release (i.e. 7.2,7.3,7.4) there are pretty significant changes, but finding a place that outlines these changes is somewhat difficult. Have you tried looking in the release notes [3]? [1] http://www.geocrawler.com/archives/3/194/1998/8/0/1061364/ [2] http://www.devx.com/dbzone/Article/20743/1763?supportItem=1 [3] http://www.postgresql.org/docs/7.4/interactive/release.html I guess I'm an ignorant fool and I don't comprehend many of the items under the release note. I'm also looking for something I can hand my boss and say ' this is why we should use postgres instead of oracle'. I think the summary of each release at the top would be OK for that. Actually, your biggest problem is that we don't have a big motivation to _sell_ PostgreSQL to anyone. We are more driven toward solving problems and designing superior software. If it looks like we don't have a polished sales image, that's because we don't stive for that. However, we have had a large number of volunteers over the past few months focus in this area and I hope there will be visible results shortly. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Tue, 27 Apr 2004, Tim Conrad wrote: On Tue, Apr 27, 2004 at 12:58:59PM -0300, Marc G. Fournier wrote: On Tue, 27 Apr 2004, Tim Conrad wrote: 2) There doesn't seem to be a clear roadmap on Postgres features. When certian things are expected. There's the TODO list that Bruce maintains, but it only outlines 'near' fixes. MySQL has a nice listing of what to expect in certian future versions. Not possible for us, since we have no upper management that dictates what features get added, for when ... Not entirely true. I've read enough on the lists to see Bruce or others saying 'x feature isn't expected until version y.z'. Heck, to me, something that says 'we're hoping for feature x in version y.z', but it's not an exact science. See the MySQL releases as an example :) Ah, then in that case, look at the TODO list, pull out all items that have a name beside them, and for those, they aren't expected until the next version .. :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Not entirely true. I've read enough on the lists to see Bruce or others saying 'x feature isn't expected until version y.z'. Heck, to me, something that says 'we're hoping for feature x in version y.z', but it's not an exact science. See the MySQL releases as an example :) Ah, then in that case, look at the TODO list, pull out all items that have a name beside them, and for those, they aren't expected until the next version .. :) But the list is lnng...and my brain is weeekkk. :) Seriously, though. I was looking through the list yesterday trying to figure out something, and it was kind of hard to do.But, more to my point, this stuff is in the MySQL manual, making it easy to find. (Yes. I know what MySQL includes kind of blows, but, it's better than nothing) Tim ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Tue, Apr 27, 2004 at 12:57:46PM -0400, Tim Conrad wrote: Seriously, though. I was looking through the list yesterday trying to figure out something, and it was kind of hard to do.But, more to my point, this stuff is in the MySQL manual, making it easy to find. (Yes. I know what MySQL includes kind of blows, but, it's better than nothing) You know, that's kind of the point of all things related to MySQL. It's better than nothing. PostgreSQL doesn't do things because it's better than nothing. My first patch here was rejected, not because it didn't do anything useful (it did), but because it didn't solve the complete problem. I had to do a lot more work to get it accepted. Similarly, people here don't want to showcase a list of things that will be on the next release, because we _don't know_ what will be on the next release. There are guesses, but guesses are not good enough. (Same as how MySQL guesses the result of a modulo operation, and gets it wrong. They don't care and you can read that on the manual. In Postgres, this is a bug.) In PostgreSQL there are no guesses. There are certainties. And I think this it how it should be for a database server ;-) -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) No hay cielo posible sin hundir nuestras raíces en la profundidad de la tierra(Malucha Pinto) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Alexey Borzov wrote: Hi! Tim Conrad wrote: My favourite part of it is: MySQL uses traditional row-level locking. PostgreSQL uses something called Multi Version Concurrency Control (MVCC) by default. MVCC is a little different from row-level locking in that transactions on the database are performed on a snapshot of the data and then serialized. New versions of PostgreSQL support standard row-level locking as an option, but MVCC is the preferred method. Nice that you point out that incorrectly stated something. Even nicer that you don't tell me what the correct answer would be. Unfortunanatly, that's the best I could come up with with doing research with the documentation I could find on the subject. MVCC does a lot more than can be easily contained in a sentance. The problem is that in MySQL 1) MyISAM does table-level locking; 2) BDB does row-level locking; 3) InnoDB does MVCC (mostly) like PostgreSQL. PostgreSQL does support row-level locking (SELECT ... FOR UPDATE), table-level locking (LOCK TABLE ...), though this does not *replace* MVCC, as one may understand from the quotation. MySQL's roadmap is complete bullshit. Subselects were first promised in 4.0, which was not that far away [1] back in 1998! Well, they are in 4.1, which is still alpha in 2004. I realize this. I also realize that having a nicely defined roadmap would give Postgres a hands up in this category. A hands up in *what* category? In bragging? Should PostgreSQL developers write something along the lines of PostgreSQL 9i (available Really Soon Now) will also be able to make coffee? Well, as you know about coffee now, why don't you add make coffee to your comparison table, with empty space in MySQL's and commercial DBMSs' columns and in 9i in PostgreSQL's one? Maybe. Just for jest-- If you read the Linux Coffee how-to, write a C module, get the right hardware, etc. Yes, PostgreSQL can make coffee! Of course, this would occur outside any sort of transactional control... Seriously, though... I think that it would be helpful to have a list of features which are under active development (not just the ToDo list which are features which we want to develop). We could also have contact info for leads (or maybe a contact via a web form, etc.) as well as status for that feature. As the lead in a project whose roadmap has changed many times due to paid contracts, I don't really see the value of published roadmaps in general. Best Wishes, Chris Travers ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Bruce Momjian wrote: Peter Eisentraut wrote: Rob wrote: But I think there is room to go further, I don't see any reason why that default install can't include example DBs, One reason is that a useful example database would likely have a download footprint of 10 MB or more. Having this in the default download would not be appreciated by many people. Of course having some example database available at all would be a good idea, but then as a separate download. Here is a little psql script I wrote to populate a table with random data. [snip] Right, I have done the same in the past using random character data (it even had random lengths of strings in the different fields) and in other cases random dictionary words. I was thinking something with more structure, like an customer/product/invoice db with random records that link up to each other properly. I will work on something but am wondering if there are any freely available schemas around (for any system, I know Sybase has a book publishing one that they use in their example queries and is provided with their install, pubs2 I believe) that might be good for use in a more extended sample db. Are there any platforms (outside of MS Windows) that don't include a word list or dictionary these days? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Bruno Wolff III wrote: On Fri, Apr 23, 2004 at 16:36:57 -0400, [EMAIL PROTECTED] wrote: Ease of use is VERY important, but few suggestions that address this are ever really accepted. Yes, focusing on the functionality is the primary concern, but how you set it up and deploy it is VERY important. You guys need to remember, people are coming from a world where MySQL, Oracle, and MSSQL all have nice setup programs. nice must be in the eye of the beholder. I have used Oracle's installer to install a client and was not amused by it need hundreds of megabtyes to do a client install. I have to agree, I've installed DB2, Sybase, Oracle, Informix, BerkeleyDB, mySQL, postgreSQL and others. IIRC, I believe postgreSQL was the shortest from download to running system (when compiling the OS ones from scratch) and seemed to do the most thorough testing of itself. Oracle doesn't seem to give you the option to not install the hundreds of megs of documentation on the Nth machine where you just needed the damn client lib - less of an issue now than in the smaller disk/partition days. But I think there is room to go further, I don't see any reason why that default install can't include example DBs, sample maintenance scripts, etc. One nice thing to have would be a sample DB with the scripts necessary to spin up a test/demo DB with a size of X megs. Whenever I started with a new DB system, I wished I didn't have to ramp up on a bunch of topics before I was able to build a set of scripts to generate and populate a sizable testing db. There is a big psychological factor if you can install something, type one command and have a db with 250,000 records to start playing with. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Bruno Wolff III wrote: On Fri, Apr 23, 2004 at 16:36:57 -0400, [EMAIL PROTECTED] wrote: Ease of use is VERY important, but few suggestions that address this are ever really accepted. Yes, focusing on the functionality is the primary concern, but how you set it up and deploy it is VERY important. You guys need to remember, people are coming from a world where MySQL, Oracle, and MSSQL all have nice setup programs. nice must be in the eye of the beholder. I have used Oracle's installer to install a client and was not amused by it need hundreds of megabtyes to do a client install. I second that. I have not found *anybody* who has used Oracle's installer to install the actual database server on Linux or Solaris who has described their installation proceedure as either nice or easy. In fact even reading the installation isntructions is enough to give you second thoughts MS SQL does have a nice installer, however, as do most binary open source products for Windows. I am completely confident that PostgreSQL for Windows, when it arrives, will have a nice GUI-based installer. Best Wishes, Chris Travers Metatron Technology Consulting begin:vcard fn:Chris Travers n:Travers;Chris email;internet:[EMAIL PROTECTED] x-mozilla-html:FALSE version:2.1 end:vcard ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Rob wrote: But I think there is room to go further, I don't see any reason why that default install can't include example DBs, One reason is that a useful example database would likely have a download footprint of 10 MB or more. Having this in the default download would not be appreciated by many people. Of course having some example database available at all would be a good idea, but then as a separate download. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Peter Eisentraut wrote:
Rob wrote:
But I think there is room to go further, I don't see any reason why
that default install can't include example DBs,
One reason is that a useful example database would likely have a
download footprint of 10 MB or more. Having this in the default
download would not be appreciated by many people. Of course having
some example database available at all would be a good idea, but then
as a separate download.
Here is a little psql script I wrote to populate a table with random
data.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
\set ECHO all
\timing
DROP TABLE perftest;
CREATE TABLE perftest (col text);
-- prime table with one row
INSERT INTO perftest VALUES ('0.364461265208414');
-- continously double the table size
INSERT INTO perftest SELECT random()::text FROM perftest;
INSERT INTO perftest SELECT random()::text FROM perftest;
INSERT INTO perftest SELECT random()::text FROM perftest;
INSERT INTO perftest SELECT random()::text FROM perftest;
INSERT INTO perftest SELECT random()::text FROM perftest;
INSERT INTO perftest SELECT random()::text FROM perftest;
INSERT INTO perftest SELECT random()::text FROM perftest;
INSERT INTO perftest SELECT random()::text FROM perftest;
INSERT INTO perftest SELECT random()::text FROM perftest;
INSERT INTO perftest SELECT random()::text FROM perftest;
INSERT INTO perftest SELECT random()::text FROM perftest;
INSERT INTO perftest SELECT random()::text FROM perftest;
INSERT INTO perftest SELECT random()::text FROM perftest;
INSERT INTO perftest SELECT random()::text FROM perftest;
-- insert a constant in the middle of the table, for use later
INSERT INTO perftest VALUES ('0.608254158221304');
INSERT INTO perftest SELECT random()::text FROM perftest;
-- 32770 rows
-- vacuum, create index
VACUUM ANALYZE perftest;
CREATE INDEX i_perftest ON perftest (col);
-- reduce chance of checkpoint during tests
CHECKPOINT;
-- turn on logging
SET log_duration = TRUE;
SET client_min_messages = 'log';
-- run normal and prepared queries
SELECT col FROM perftest WHERE col = '0.608254158221304';
SELECT col FROM perftest WHERE col = '0.608254158221304';
SELECT col FROM perftest WHERE col = '0.608254158221304';
SELECT col FROM perftest WHERE col = '0.608254158221304';
SELECT col FROM perftest WHERE col = '0.608254158221304';
PREPARE perftest_prep (text) AS SELECT col FROM perftest WHERE col = $1;
EXECUTE perftest_prep ('0.608254158221304');
EXECUTE perftest_prep ('0.608254158221304');
EXECUTE perftest_prep ('0.608254158221304');
EXECUTE perftest_prep ('0.608254158221304');
EXECUTE perftest_prep ('0.608254158221304');
-- first time the entire statement
SET log_statement_stats = TRUE;
-- run normal and prepared queries
SELECT col FROM perftest WHERE col = '0.608254158221304';
SELECT col FROM perftest WHERE col = '0.608254158221304';
SELECT col FROM perftest WHERE col = '0.608254158221304';
SELECT col FROM perftest WHERE col = '0.608254158221304';
SELECT col FROM perftest WHERE col = '0.608254158221304';
PREPARE perftest_prep (text) AS SELECT col FROM perftest WHERE col = $1;
EXECUTE perftest_prep ('0.608254158221304');
EXECUTE perftest_prep ('0.608254158221304');
EXECUTE perftest_prep ('0.608254158221304');
EXECUTE perftest_prep ('0.608254158221304');
EXECUTE perftest_prep ('0.608254158221304');
-- now log each query stage
SET log_statement_stats = FALSE;
SET log_parser_stats = TRUE;
SET log_planner_stats = TRUE;
SET log_executor_stats = TRUE;
-- run normal and prepared queries
SELECT col FROM perftest WHERE col = '0.608254158221304';
SELECT col FROM perftest WHERE col = '0.608254158221304';
SELECT col FROM perftest WHERE col = '0.608254158221304';
SELECT col FROM perftest WHERE col = '0.608254158221304';
SELECT col FROM perftest WHERE col = '0.608254158221304';
EXECUTE perftest_prep ('0.608254158221304');
EXECUTE perftest_prep ('0.608254158221304');
EXECUTE perftest_prep ('0.608254158221304');
EXECUTE perftest_prep ('0.608254158221304');
EXECUTE perftest_prep ('0.608254158221304');
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Tom Lane wrote: Aside from the reality that apps aren't very consistent about their quoting behavior, the fly in this ointment is that whenever you query the database catalogs you will see the stored spelling of the name. So apps that rely on seeing the same spelling in the catalog that they entered could break. (In practice this doesn't seem to be as big a problem as the sloppy-quoting-behavior issue, though.) Shouldn't apps only really be querying the information schema if they're expecting spec compliant behavior? If so, a GUC variable with an access function ought to be enough to get up or down casing as desired, I'd think. Joe ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Fri, Apr 23, 2004 at 10:56:43PM -0700, Joe Conway wrote: Tom Lane wrote: Aside from the reality that apps aren't very consistent about their quoting behavior, the fly in this ointment is that whenever you query the database catalogs you will see the stored spelling of the name. So apps that rely on seeing the same spelling in the catalog that they entered could break. (In practice this doesn't seem to be as big a problem as the sloppy-quoting-behavior issue, though.) Shouldn't apps only really be querying the information schema if they're expecting spec compliant behavior? If so, a GUC variable with an access function ought to be enough to get up or down casing as desired, I'd think. Some questions: Is there a way to make this work? At what level should the current system be modified? If the parser or lexer is to be modified, are they going to need database access? They are not allowed to, AFAIR. One could invent a GUC setting for this, and have it set at database creation time. How would shared catalogs be handled? Should we have a template database for uppercase and another one for lower case databases? Should non-shared catalogs be handled in a special way? Or maybe it is a compilation switch. What issues would arise? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Before you were born your parents weren't as boring as they are now. They got that way paying your bills, cleaning up your room and listening to you tell them how idealistic you are. -- Charles J. Sykes' advice to teenagers ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Fri, Apr 23, 2004 at 11:45:28AM -0400, Robert Treat wrote: lower will now simply be folder upper. the only people who will have a problem are those who quote on one end but not the other, which is bad practice anyways... so i would say if your serious about it, make the patch as GUC case_folding for upper or lower and get a taste for what breaks inside the db. If it were that easy, it wouldn't matter, right? That is, if you had a system which was either consistently quoted or consistently unquoted, then you'd never run into the problem of the upper-or-lower question. It's precisely _because_ systems often have been maintained by various cranks for 20 years that it's a problem. One guy thinks quoting is stupid. Another thinks that if you don't quote, you're asking for trouble, A third has been rigourous in following the quoting convention he learned in his last job. The ship date is three weeks away, and there are 802 P1 bugs filed. What chance do you think there is that someone is going to scrub all the checkins of quotes (or apply them carefully)? This is _exactly_ why standards compliance for this stuff matters, and why backward comaptibility is also a top priority. A -- Andrew Sullivan | [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Fri, 2004-04-23 at 05:22, Dennis Bjorklund wrote:
On Fri, 23 Apr 2004, Shachar Shemesh wrote:
When I ask about non-standard complience of Pg (turning unquoted
identifiers to lowercase instead of uppercase, violating the SQL
standard, and requring an expensive rewrite of clients), and I get the
answer uppercase is ugly, I think something is wrong.
I would love if someone fixed pg so that one can get the standard
behaviour. It would however have to be a setting that can be changed so we
are still backward compatible.
that even if I write a patch to start migration, I'm not likely to get
it in.
Just changing to uppercase would break old code so such a patch should not
just be commited. But would people stop a patch that is backward
compatible (in the worst case a setting during initdb)? I'm not so sure
they will.
I know this to be true, but don't fully understand it... if our default
behavior is to fold lower, and we change it to just fold upper... then
in theory this shouldn't break anything since what used to be folder
lower will now simply be folder upper. the only people who will have a
problem are those who quote on one end but not the other, which is bad
practice anyways... so i would say if your serious about it, make the
patch as GUC case_folding for upper or lower and get a taste for what
breaks inside the db.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Fri, 23 Apr 2004, Robert Treat wrote: On Fri, 2004-04-23 at 05:22, Dennis Bjorklund wrote: On Fri, 23 Apr 2004, Shachar Shemesh wrote: When I ask about non-standard complience of Pg (turning unquoted identifiers to lowercase instead of uppercase, violating the SQL standard, and requring an expensive rewrite of clients), and I get the answer uppercase is ugly, I think something is wrong. I would love if someone fixed pg so that one can get the standard behaviour. It would however have to be a setting that can be changed so we are still backward compatible. that even if I write a patch to start migration, I'm not likely to get it in. Just changing to uppercase would break old code so such a patch should not just be commited. But would people stop a patch that is backward compatible (in the worst case a setting during initdb)? I'm not so sure they will. I know this to be true, but don't fully understand it... if our default behavior is to fold lower, and we change it to just fold upper... then in theory this shouldn't break anything since what used to be folder lower will now simply be folder upper. the only people who will have a problem are those who quote on one end but not the other, which is bad practice anyways... so i would say if your serious about it, make the patch as GUC case_folding for upper or lower and get a taste for what breaks inside the db. I've tried just changing the parser to unconditionally casefold to upper. First thing that happens is that initdb breaks. In addition, you have potential issues with comparisons against the catalog's versions of standard functions as such if you allow the case folding to be changed after the catalogs are setup. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Stephan Szabo wrote: I know this to be true, but don't fully understand it... if our default behavior is to fold lower, and we change it to just fold upper... then in theory this shouldn't break anything since what used to be folder lower will now simply be folder upper. the only people who will have a problem are those who quote on one end but not the other, which is bad practice anyways... so i would say if your serious about it, make the patch as GUC case_folding for upper or lower and get a taste for what breaks inside the db. I've tried just changing the parser to unconditionally casefold to upper. First thing that happens is that initdb breaks. In addition, you have potential issues with comparisons against the catalog's versions of standard functions as such if you allow the case folding to be changed after the catalogs are setup. ISTM that rather than a having a GUC setting, initdb would be the right time to make this choice. I'm not saying it would be easy, but it seems (without looking into it deeply) at least possible. cheers andrew ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Fri, 2004-04-23 at 13:11, Andrew Dunstan wrote:
Stephan Szabo wrote:
I know this to be true, but don't fully understand it... if our default
behavior is to fold lower, and we change it to just fold upper... then
in theory this shouldn't break anything since what used to be folder
lower will now simply be folder upper. the only people who will have a
problem are those who quote on one end but not the other, which is bad
practice anyways... so i would say if your serious about it, make the
patch as GUC case_folding for upper or lower and get a taste for what
breaks inside the db.
I've tried just changing the parser to unconditionally casefold to upper.
First thing that happens is that initdb breaks. In addition, you have
potential issues with comparisons against the catalog's versions of
standard functions as such if you allow the case folding to be changed
after the catalogs are setup.
ISTM that rather than a having a GUC setting, initdb would be the right
time to make this choice. I'm not saying it would be easy, but it seems
(without looking into it deeply) at least possible.
This implies that the standard functions are created with explicit
quoting to make the lower case named? Shouldn't all functions be
created without any quoting so they fold to whichever way the settings
are set? Hmm... I see your angle Andrew.. they are going to be created
one way or the other so you'd be hard pressed to do it at any time other
than initdb time... of course you could just create duplicates of all
the functions in both upper and lower case, that way whichever way you
fold it matches :-)
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Robert Treat wrote: On Fri, 2004-04-23 at 13:11, Andrew Dunstan wrote: Stephan Szabo wrote: I know this to be true, but don't fully understand it... if our default behavior is to fold lower, and we change it to just fold upper... then in theory this shouldn't break anything since what used to be folder lower will now simply be folder upper. the only people who will have a problem are those who quote on one end but not the other, which is bad practice anyways... so i would say if your serious about it, make the patch as GUC case_folding for upper or lower and get a taste for what breaks inside the db. I've tried just changing the parser to unconditionally casefold to upper. First thing that happens is that initdb breaks. In addition, you have potential issues with comparisons against the catalog's versions of standard functions as such if you allow the case folding to be changed after the catalogs are setup. ISTM that rather than a having a GUC setting, initdb would be the right time to make this choice. I'm not saying it would be easy, but it seems (without looking into it deeply) at least possible. This implies that the standard functions are created with explicit quoting to make the lower case named? Shouldn't all functions be created without any quoting so they fold to whichever way the settings are set? Hmm... I see your angle Andrew.. they are going to be created one way or the other so you'd be hard pressed to do it at any time other than initdb time... of course you could just create duplicates of all the functions in both upper and lower case, that way whichever way you fold it matches :-) That strikes me as an instant recipe for shooting yourself in the foot, as well as providing useless catalog bloat. Things need *one* canonical name, IMNSHO. cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Fri, 2004-04-23 at 14:28, Andrew Dunstan wrote:
Robert Treat wrote:
of course you could just create duplicates of all
the functions in both upper and lower case, that way whichever way you
fold it matches :-)
That strikes me as an instant recipe for shooting yourself in the foot,
as well as providing useless catalog bloat. Things need *one* canonical
name, IMNSHO.
hence the smiley...
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Stephan Szabo wrote: I've tried just changing the parser to unconditionally casefold to upper. First thing that happens is that initdb breaks. In addition, you have potential issues with comparisons against the catalog's versions of standard functions as such if you allow the case folding to be changed after the catalogs are setup. That's not the migration path I was thinking of. What I was thinking of was: 1. Have a setting, probably per-session. Per database works too. 2. Aside from the folder upper and folder lower, have a third option. This is fold upper, if fails, fold lower. If succeeds, issue a warning. This should allow programs that rely on the folding (such as initdb) to be debugged during the transition period. Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Fri, 23 Apr 2004, Shachar Shemesh wrote: Stephan Szabo wrote: I've tried just changing the parser to unconditionally casefold to upper. First thing that happens is that initdb breaks. In addition, you have potential issues with comparisons against the catalog's versions of standard functions as such if you allow the case folding to be changed after the catalogs are setup. That's not the migration path I was thinking of. What I was thinking of was: 1. Have a setting, probably per-session. Per database works too. 2. Aside from the folder upper and folder lower, have a third option. This is fold upper, if fails, fold lower. If succeeds, issue a warning. This should allow programs that rely on the folding (such as initdb) to be debugged during the transition period. If you can do this in a clean fashion without tromping all around the code, that'd be reasonable, however, istm that you'd need to either pre-fold both directions from the given identifier string and pass an extra copy around or pass the original identifier and its quoted status and fold on use. I think either of these are likely to be very intrusive for what essentially amounts to a transitional feature. In addition, I'm not sure that this would always work in any case, since some of those usages may be quoted identifiers that were once generated from a case-folded string (for example, looking up a name in the catalogs and quoting it). ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Fri, 23 Apr 2004, Stephan Szabo wrote: On Fri, 23 Apr 2004, Shachar Shemesh wrote: Stephan Szabo wrote: I've tried just changing the parser to unconditionally casefold to upper. First thing that happens is that initdb breaks. In addition, you have potential issues with comparisons against the catalog's versions of standard functions as such if you allow the case folding to be changed after the catalogs are setup. That's not the migration path I was thinking of. What I was thinking of was: 1. Have a setting, probably per-session. Per database works too. 2. Aside from the folder upper and folder lower, have a third option. This is fold upper, if fails, fold lower. If succeeds, issue a warning. This should allow programs that rely on the folding (such as initdb) to be debugged during the transition period. If you can do this in a clean fashion without tromping all around the code, that'd be reasonable, however, istm that you'd need to either pre-fold both directions from the given identifier string and pass an extra copy around or pass the original identifier and its quoted status and fold on use. I think either of these are likely to be very intrusive for what essentially amounts to a transitional feature. In addition, I'm not sure that this would always work in any case, since some of those usages may be quoted identifiers that were once generated from a case-folded string (for example, looking up a name in the catalogs and quoting it). To clarify, I'm thinking about things where an application had gotten a quoted name and is now trying to use it where the object's canonical name was changed due to quoting changes. This only happens when quoting is inconsistently applied, but that's most of the problem. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Stephan Szabo [EMAIL PROTECTED] writes: To clarify, I'm thinking about things where an application had gotten a quoted name and is now trying to use it where the object's canonical name was changed due to quoting changes. This only happens when quoting is inconsistently applied, but that's most of the problem. Actually, that's *all* the problem, at least as far as SQL commands are concerned. If you are consistent about always quoting or never quoting a particular name, you can't tell the difference between PG's behavior and SQL-spec behavior. Aside from the reality that apps aren't very consistent about their quoting behavior, the fly in this ointment is that whenever you query the database catalogs you will see the stored spelling of the name. So apps that rely on seeing the same spelling in the catalog that they entered could break. (In practice this doesn't seem to be as big a problem as the sloppy-quoting-behavior issue, though.) Personally I don't think that this is a transitional issue and we will someday all be happy in upper-case-only-land. Upper-case-only sucks, by every known measure of readability, and I don't want to have to put up with a database that forces that 1960s-vintage-hardware mindset on me. So what I'm holding out for is a design that lets me continue to see the current behavior if I set a GUC variable that says that's what I want. This seems possible (not easy, but possible) if we are willing to require the choice to be made at compile time ... but that sounds too restrictive to satisfy anybody ... what we need is a design that supports such a choice per-session, and I dunno how to do that. regards, tom lane PS: I resisted the temptation to SET THIS MESSAGE IN ALL UPPER CASE to make the point about readability. But if you want to argue the point with me, I'll be happy to do that for the rest of the thread. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Sat, 24 Apr 2004, Tom Lane wrote: Upper-case-only sucks, by every known measure of readability, and I don't want to have to put up with a database that forces that 1960s-vintage-hardware mindset on me. Well, get used to it :-) So what I'm holding out for is a design that lets me continue to see the current behavior if I set a GUC variable that says that's what I want. Wouldn't the upper case identifiers just be visible in the \d output, table headers and such. You could still have psql tab completion produce lower case identifiers (if told using some setting). Even if the database store all non quoted names as upper case I would still use lower case in all applications and on the psql command line. It's not a big problem for me if the output of \d and the table headers and such is in upper case. One would get used to it fase. And maybe one can even store an extra bit telling if the string was created with or without quotes and have psql lower case all the ones created without quotes. First I thought that one can store the string with case all the time, and just convert when needed (when comparing identifiers). Perhaps using the non existant locale support and locales such as SQL_UPPER or SQL_MIXED. But it wont work since it would make Foo and Foo clash. When translated directly it would create separate entries Foo and FOO. ps. And if you want to play the WRITE MAILS USING ONLY UPPER CASE, BE MY GUEST! -- /Dennis Björklund ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Dennis Bjorklund [EMAIL PROTECTED] writes: On Sat, 24 Apr 2004, Tom Lane wrote: So what I'm holding out for is a design that lets me continue to see the current behavior if I set a GUC variable that says that's what I want. Wouldn't the upper case identifiers just be visible in the \d output, table headers and such. Exactly ... and that's where my readability complaint starts ... First I thought that one can store the string with case all the time, and just convert when needed (when comparing identifiers). People keep suggesting these random not-quite-standard behaviors, but I fail to see the point. Are you arguing for exact standards compliance, or not? If you're not, then you have to make your case on the claim that my nonstandard behavior is better than the existing nonstandard behavior. Which might be true, beauty being in the eye of the beholder, but I doubt you can prove it to the extent of overriding the backwards-compatibility issue. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Sat, 24 Apr 2004, Tom Lane wrote: First I thought that one can store the string with case all the time, and just convert when needed (when comparing identifiers). People keep suggesting these random not-quite-standard behaviors, but I fail to see the point. Are you arguing for exact standards compliance, or not? That was me making conversation, pointing out something that does not work. Since it does not work I don't want it to be implemented. And with work I mean not follow the standard. For something to follow standard it has to behave the correct way to the outside, how it's implemented is a different matter. The above does not work. Period. -- /Dennis Björklund ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
