Thread: Re: [GENERAL] Is my MySQL Gaining ?
On Sunday 28 December 2003 11:15, D. Dante Lorenso wrote: > The only SQL customizations that MySQL has that I really miss in PostgreSQL > are the commands: > > SHOW DATABASES; \l > SHOW TABLES; \dt > DESC table; \d tablename > > That was ubber simple to do in MySQL. To this day, I have trouble with > that in PostgreSQL. I'm constantly doing: > > psql> \? > psql> help; > ERROR: syntax error at or near "help" at character 1 > psql> \h > ... > * damnit, that's not it...* > psql> \? > psql> \d > * ok, now which flag do I use for tables vs functions..etc?* \df for functions and \dt for tables. Problem is psql is unique though very powerful. I need to use oracle's sql-plus on HP-UX at times(Otherwise I crawl back to TOAD) and I don't think it is nowhere near to psql. or may be I play with postgresql more than oracle..:-) anyways > I finally figure it out, I just end up forgetting again later. I still > have no clue how I'd find the same data without using psql. In MySQL > I can run those queries from PHP, PERL...etc. I know you can find that > data in system tables in PostgreSQL, but I don't wanna muck around with > all that. I just wanna do something as simple as MySQL. Well, actually I would say it is great way of learning postgresql internals. There is a switch -E to psql which shows you queries sent to server for each command you provide. Problem with mysql is the approach is easy to start with but adding those command in your standard list of SQL commands falls out on standard compliance and maintainability. Another post on this thread mentioned postgresql should run against oracle. Sole reason postgresql v/s mysql debate should exist is to provide comparision in feasibility study. The hurdles you mentioned are true but that are just part of bit steeper learning curve of a standard way of doing things.. Shridhar
On Sunday 28 December 2003 23:50, Keith C. Perry wrote: > Quoting Shridhar Daithankar <shridhar_daithankar@myrealbox.com>: > > are just part of bit steeper learning curve of a standard way of doing > > things.. > This is what I don't get. Why do people thing learn PG is going to be like > learning MySQL in the first place? Because its OSS?? I certainly hope > not. This is apples to oranges. Certainly.. but people do that. Because copmparing unknown to a known idea is only way to learn it. If all I know is mysql, I am going to try and model postgresql to fit mysql point of view. Soon enough postgresql will grow out of it but that is a different story. > I read someone say the documentation was "light" too. I'm not sure what > that meant but I looked for at the 3 inch doubled side binded of my 7.3.2 > docs- admin,user &,programmer- its as big as my J2EE binder. That is right. but that fact remains that postgresql documentation is just sufficient. If you read the manual and follow it religously to comma and fullstop, it tells you everythings. But it certainly isn't a place where you can glance over it and get hang of it. Now how good practice of 'glance over and get hang of it' is, remains a topic of debate though..:-) Shridhar
On Monday 29 December 2003 12:47, Tom Lane wrote: > Shridhar Daithankar <shridhar_daithankar@myrealbox.com> writes: > > That is right. but that fact remains that postgresql documentation is > > just sufficient. If you read the manual and follow it religously to comma > > and fullstop, it tells you everythings. But it certainly isn't a place > > where you can glance over it and get hang of it. > > This is surely true, and I've not seen anyone denying it. The people Well, for newbies to postgresql, let's state this fact upfront and not make them discover it..:-) > who are doing development are, um, not strong at documentation (I > include myself here). What we need are some folks to step up and > improve the documentation --- and then maintain it in the face of future > changes. Any volunteers out there? This is an open-source project > after all, and that means "scratch your own itch" among other things... If you ask me, let's not do that. Not at least on a grand scale. Isolated areas are OK on case by case basis.. I regualrly use development build documentation from developers.postgresql.org and I have seen the documentation in source code. In my view, postgresql developers do document it very clearly whenever required. If we dilute the documentation too much, that will make things simpler initially but that will simply create a maintainance nightmare as one has to maintain much larger amount of documentation. And once you get used to precise style of postgresql documentation, going back to anything else is a pain. ( MSDN.. I scream at nights.... but I digress). IMO documentation of postgresql is fine overall. What we need to do is. 1. State upfront that this is not handholding. It will make lots of things easier and offload work of expanding documents given limited human resources working on the project. A disclaimer is far easier to maintain than a manual..:-) And it will prepare anybody for upcoming hardships..:-) 2. Document and reuse it. Personally I would like to see responses on general and oter such list as URLs. If we answer it repeatedly, let's document it and point the people to them. Let them dig around 3-4 URLs around it and they will have islands of enlightenments. Over the period, these island will merge in a great landscape..:-) Just a thought.. Shridhar P.S. If somebody thinks I can not imagine how a newbie feels, I will agree. But looking back, dumbing down anything is not good in long term..an experience that is
On Monday 29 December 2003 14:40, Tony wrote: > I agree with you (speaking as a newbie) I don't believe any dumbing down > is necessary at all. I DO believe however that a decent introduction to > the more important concepts (Triggers, Fkeys, Stored Proc, Views) that > people from lesser systems (MySQL, Access) may not be familiar with. > What they do, how they help, and why they are generally a good thing. > This intro would probably fit either in the tutorial or in the User Guide. > > Don't hold peoples hand for them, but at least provide them with the > tools they need to make an educated decision. For one thing, these thing do not belong to postgresql documentation. But I don't believe there is shortage of material on these topics on web and in print. However if you are refering to explaining these things, w.r.t. postgresql, I would be more than happy to churn out some extremely basic tutorials. Can you tell us what all you need? Rephrasing, if you know these(and some other) concpets by now, what all you missed while learning postgresql? It may sound like stupid question but unlearning things out of imagination is not easy...:-) Shridhar
On Monday 29 December 2003 15:25, Tony wrote: > By that logic then, we can probably ditch the PG Tutorial altogether and > provide a quick ref card of PG commands and keywords, with a few pages > on how PG is different should be plenty. > > The bisggest problem that I faced when moving to PG was the complete > lack of any cetralised information source for this information. Sure > there are tutorials on the web, first track them down, then convert > their use to PG then collate them, then make some sense of it all. > This is the kind of aloofness that I have mentioned previously, just > because it doesn't belong, doesn't mean it's not needed, and it only > needs to be written once. Although I know some of the concepts and I'm > beginning to grock them, I'm still trying to collate enough to satisfy > my needs. > > Assuming yo *do* want to grow the PG community and attract people from > other systems, the easier the transition for them, the less likely they > are to look elsewhere for something that appears easier. Easier > doesn't always mean easier to use, sometimes it can mean easier to get > to grips with. *Sigh*.. You just read my first remark which you could have bypassed but anyways.. What do you think of offer I made? I was slightly disappointed to see that you missed it.. I am not removing my original message. Please read and let me know what do you think.. > > Shridhar Daithankar wrote: > >For one thing, these thing do not belong to postgresql documentation. > > > >But I don't believe there is shortage of material on these topics on web > > and in print. > > > >However if you are refering to explaining these things, w.r.t. postgresql, > > I would be more than happy to churn out some extremely basic tutorials. > > > >Can you tell us what all you need? Rephrasing, if you know these(and some > >other) concpets by now, what all you missed while learning postgresql? > > > >It may sound like stupid question but unlearning things out of imagination > > is not easy...:-) Shridhar
Hi all; I am working on an outline for topics that I think should have detailed discussion and/or tutorial items. Unfortunately my laptop is in the shop (bad motherboard) but when it comes back, I will post it. I think that Shrindhar is right-- these things do not belong in the main documentation which should be complete, technical, and accessible. But instead, I think that we need a separate document which teaches someone how to use an enterprise RDBMS, and particularly PostgreSQL. Learning these topics piecemeal is not very helpful, IMO :-( I hope that the progression will be: Outline -> disjointed tutorials -> integrated mega-tutorial -> larger curriculum set. Best Wishes, Chris Travers ----- Original Message ----- From: "Shridhar Daithankar" <shridhar_daithankar@myrealbox.com> To: "Tony" <tony@unihost.net> Cc: <pgsql-general@postgresql.org>; <pgsql-advocacy@postgresql.org> Sent: Monday, December 29, 2003 5:14 PM Subject: Re: [pgsql-advocacy] [GENERAL] Is my MySQL Gaining ? > On Monday 29 December 2003 15:25, Tony wrote: > > By that logic then, we can probably ditch the PG Tutorial altogether and > > provide a quick ref card of PG commands and keywords, with a few pages > > on how PG is different should be plenty. > > > > The bisggest problem that I faced when moving to PG was the complete > > lack of any cetralised information source for this information. Sure > > there are tutorials on the web, first track them down, then convert > > their use to PG then collate them, then make some sense of it all. > > This is the kind of aloofness that I have mentioned previously, just > > because it doesn't belong, doesn't mean it's not needed, and it only > > needs to be written once. Although I know some of the concepts and I'm > > beginning to grock them, I'm still trying to collate enough to satisfy > > my needs. > > > > Assuming yo *do* want to grow the PG community and attract people from > > other systems, the easier the transition for them, the less likely they > > are to look elsewhere for something that appears easier. Easier > > doesn't always mean easier to use, sometimes it can mean easier to get > > to grips with. > > *Sigh*.. You just read my first remark which you could have bypassed but > anyways.. > > What do you think of offer I made? I was slightly disappointed to see that you > missed it.. > > I am not removing my original message. Please read and let me know what do you > think.. > > > > > Shridhar Daithankar wrote: > > >For one thing, these thing do not belong to postgresql documentation. > > > > > >But I don't believe there is shortage of material on these topics on web > > > and in print. > > > > > >However if you are refering to explaining these things, w.r.t. postgresql, > > > I would be more than happy to churn out some extremely basic tutorials. > > > > > >Can you tell us what all you need? Rephrasing, if you know these(and some > > >other) concpets by now, what all you missed while learning postgresql? > > > > > >It may sound like stupid question but unlearning things out of imagination > > > is not easy...:-) > > Shridhar > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > >
Hello, How about just a "Getting Started with PostgreSQL" guide... Python is like this. They have the "real" documentation but they also have a introductory tutorial. We could have a brief document (100 pages or less) that talks about the basic concepts of PostgreSQL... Sincerely, Joshua D. Drake Shridhar Daithankar wrote: >On Monday 29 December 2003 12:47, Tom Lane wrote: > > >>Shridhar Daithankar <shridhar_daithankar@myrealbox.com> writes: >> >> >>>That is right. but that fact remains that postgresql documentation is >>>just sufficient. If you read the manual and follow it religously to comma >>>and fullstop, it tells you everythings. But it certainly isn't a place >>>where you can glance over it and get hang of it. >>> >>> >>This is surely true, and I've not seen anyone denying it. The people >> >> > >Well, for newbies to postgresql, let's state this fact upfront and not make >them discover it..:-) > > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC - S/JDBC Postgresql support, programming, shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com
>This concerns me. This is the second time recently someone has said something >is NOT documented and it it turn out it is. > >So my question is (no offense to anyone) are the web sites not "clear" enough to >find information quickly or are people just being lax/lazy when they are searching. > > > Well, at anything greater than 1024x768 the "docs" link on the main site is near invisible. The font size is fine, but combined with the color scheme and location, it can be hard to spot... Mainly, I think because the page is so busy. If you look at the front page the first thing you see is News which is fine, but IMHO the first thing should be the nav bar comes before News but News is big, bold print. Also searching the PostgreSQL docs is a useless venture. I just typed in trigger and hit search.... 20 seconds later I am still waiting. Why don't we just add Google search to the page? Sincerely, Joshua D. Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC - S/JDBC Postgresql support, programming, shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com
Joshua D. Drake wrote: > How about just a "Getting Started with PostgreSQL" guide... Python is > like this. > They have the "real" documentation but they also have a introductory > tutorial. We > could have a brief document (100 pages or less) that talks about the > basic concepts > of PostgreSQL... Dunno if this is worth the effort, but the old Great Bridge User Guide is still out there in a bunch of places, if anyone'sinterested. The last one was for version 7.1, so it's more than a little moldy, but it did a lot of the stuff peoplehave been talking about here (more newbie-ish): http://database.ittoolbox.com/documents/document.asp?i=1371
>How would this differ from the existing Tutorial? > > Well, for one it would tell the user how to start postgresql ;) Yes I know that it provides a link to chapter 14 but IMHO the tutorial should be inclusive. New users don't want to jump all over a 1000 page document to figure out how to just start the thing up and start tinkering with it. You shouldn't need anything else to get started. Thus it would be a self contained document. PostgreSQL for Dummies.... Sincerely, Joshua D. Drake > regards, tom lane > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC - S/JDBC Postgresql support, programming, shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com
On Mon, Dec 29, 2003 at 14:31:43 -0500, "Keith C. Perry" <netadmin@vcsn.com> wrote: > > Shridhar, > > I tend to agree with you. I personally think the docs are very good and have > the techical depth warranted for a product like PostgreSQL. On the other hand > for the ad & m (advocacy and marketing) side of things. I'm betting some > clearly labelled tutorials/guide next to the disclaimer about the the main docs > be more of a reference would appease those who might be a bit green to a product > of PG breadth and depth (heck I still think I'm in the category sometimes). Even new users would be well served by skimming over the complete documentation. I don't think it is a good idea to suggest that they not read it. I think you would be better off providing references to learn about RDBMS' in general for people that don't have that background and pointing out some of the Postgres quirks that are likely to trip up people.
Tony wrote: > I already had in the first post I replied to, but at the risk of > sounding redundant, I'll say it again. > > Views: When I came to PG I didn't know what they were, saw no point > to them (still don't) why do you need a function to provide details of > a query when a more complicated query gives the same data? Are they > designed for people who don't like to type long queries? They are designed for several things IMHO. 1. So I don't have to type long queries. 2. So I can have a base query and just append where clauses, joins etc... as I need. 3. So I can provide permissions based on the view, not the table itself -- thus lending to a more flexible acl model. Sincerely, Joshua D. Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC - S/JDBC Postgresql support, programming, shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com
Bruno Wolff III wrote: > I think you would be better off providing references to learn about RDBMS' > in general for people that don't have that background and pointing out > some of the Postgres quirks that are likely to trip up people. To get the ball rolling, does anyone have these books? If so, would you be able to write a short review (respond to the list) about it? Do you have a review about some other book that you'd like to add to the list? If I can find them at the local library, I'll start working through the most favoured books to write a "PostgreSQL Study Guide" for the "better" books. The list (in order of discovery): 1) Michael J. Hernandez & John L. Viescas, "SQL Queries for Mere Mortals: A Hands-On Guide to Data Manipulation in SQL", August 2000, ISBN: 0201433362 2) Ben Forta, "Sams Teach Yourself SQL in 10 Minutes", May 2001, ISBN: 0672321289 3) Allen G. Taylor, "SQL For Dummies", July 2003, ISBN: 0764540750 (though I list this book with reservation, since IDG have been actively prosecuting people who publish any kind of "... for dummies" guide, even when the non-IDG version was around long before the "... For Dummies" books, but that's another story for another time) 4) Kevin E. Kline, Daniel L. Kline et al, "SQL in a Nutshell", January 2001, ISBN: 1565927443 5) James R. Groff & Paul N. Weinberg, "SQL: The Complete Reference", August 2002, ISBN: 0072225599 6) John J. Patrick, John Patrick, "SQL Fundamentals", May 2002, ISBN: 0130669474 7) Christian Darie, et al, "Programmer's Guide to SQL", September 2003, ISBN: 1590592182 8) Robert Sheldon, "SQL: A Beginner's Guide, 2nd Edition", May 2003, ISBN: 0072228857 9) Alex Kiregel & Boris M. Trukhnov, "SQL Bible", April 2003, ISBN: 0764525840 10) Alexander Sasha Pachev, "MySQL Enterprise Solutions", March 2003, ISBN: 0471269220 (is anyone else scared by that title?) 11) Peter Gulutzan & Trudy Pelzer, "SQL Performance Tuning", September 2002, ISBN: 0201791692 12) Kevin Thompson, et al, "Learn SQL in a Weekend", May 2002, ISBN: 1931841624 13) Allen G. Taylor, "SQL Weekend Crash Course", January 2002, ISBN: 0764549014 (I'm a little worried about the prevalence of ".. in a weekend" style books - what quality of database are people building after learning the language in a weekend?) Note that during my quick search for books about "SQL", about half of the returns were books about Microsoft SQL Server. I guess MS-SQL administrators have lots of reading time :) That list will most likely take me 12 months or more to read through myself. Anyone care to guess what version of PostgreSQL will be "current" in December 2004? Regards Alex Satrapa
On Tuesday 30 December 2003 02:28, Joshua D. Drake wrote: > >How would this differ from the existing Tutorial? > > Well, for one it would tell the user how to start postgresql ;) Like this? http://wiki.ael.be/index.php/PostgresQL101 It is linked from front page of techdocs.postgresql.org under name of Postgresql 101. Actually overall, I am thinking of some 2 page per concept on similar line but I think that is what we are talking about, right? And besides the general impression I got from this thread is that people need illustrations lot more than the project seems to anticipate. Am I off-mark here? Shridhar
I have previously made my viewpoint known regarding the need for training docs separate from the main docs.
Regarding views: Think single point of maintenance. Here are a few examples:
1: You have a complex query which is run with different restrictions in the WHERE clause. You can set up a view to make maintenance easier, so you avoid duplication of effort.
2: You have an app that expects data to be presented in a different way. You can use a view to do this.
You are right, that a view can do just what a select statement does, but particularly for extremely complex data manipulations, they are very helpful.
Here is another example:
Imagine that I have a complex database where I store historical changes to a hotel and reservations. I can then use a view to look at calculated vacancy rates. Then the vacancy rate view can be manipulated in various ways as if it were a table. Often the simple examples don't show as much as the examples that are much harder to do without a view.
Stored Procs are much the same. The advantages of stored procs are:
1) For repeated queries based on other queries, less network latency buildup.
2) Stored procs can be used from any frontend, so if a function is generally useful you might want to put it there.
If your interested, we have a book reviews section up on techdocs where several recomended have already been reviewed. Come to think of it I still owe Korry Douglas a review of his book... one thing I noticed about your list, it focuses a lot on sql. IMO this is a mistake, try to put more focus on relational theory, something that sql wont teach you. http://techdocs.postgresql.org/techdocs/bookreviews.php Robert Treat On Monday 29 December 2003 17:32, Alex Satrapa wrote: > Bruno Wolff III wrote: > > I think you would be better off providing references to learn about > > RDBMS' in general for people that don't have that background and pointing > > out some of the Postgres quirks that are likely to trip up people. > > To get the ball rolling, does anyone have these books? If so, would you > be able to write a short review (respond to the list) about it? Do you > have a review about some other book that you'd like to add to the list? > > If I can find them at the local library, I'll start working through the > most favoured books to write a "PostgreSQL Study Guide" for the "better" > books. > > The list (in order of discovery): > > 1) Michael J. Hernandez & John L. Viescas, "SQL Queries for Mere > Mortals: A Hands-On Guide to Data Manipulation in SQL", August 2000, > ISBN: 0201433362 > > 2) Ben Forta, "Sams Teach Yourself SQL in 10 Minutes", May 2001, ISBN: > 0672321289 > > 3) Allen G. Taylor, "SQL For Dummies", July 2003, ISBN: 0764540750 > (though I list this book with reservation, since IDG have been actively > prosecuting people who publish any kind of "... for dummies" guide, even > when the non-IDG version was around long before the "... For Dummies" > books, but that's another story for another time) > > 4) Kevin E. Kline, Daniel L. Kline et al, "SQL in a Nutshell", January > 2001, ISBN: 1565927443 > > 5) James R. Groff & Paul N. Weinberg, "SQL: The Complete Reference", > August 2002, ISBN: 0072225599 > > 6) John J. Patrick, John Patrick, "SQL Fundamentals", May 2002, ISBN: > 0130669474 > > 7) Christian Darie, et al, "Programmer's Guide to SQL", September 2003, > ISBN: 1590592182 > > 8) Robert Sheldon, "SQL: A Beginner's Guide, 2nd Edition", May 2003, > ISBN: 0072228857 > > 9) Alex Kiregel & Boris M. Trukhnov, "SQL Bible", April 2003, ISBN: > 0764525840 > > 10) Alexander Sasha Pachev, "MySQL Enterprise Solutions", March 2003, > ISBN: 0471269220 > (is anyone else scared by that title?) > > 11) Peter Gulutzan & Trudy Pelzer, "SQL Performance Tuning", September > 2002, ISBN: 0201791692 > > 12) Kevin Thompson, et al, "Learn SQL in a Weekend", May 2002, ISBN: > 1931841624 > > 13) Allen G. Taylor, "SQL Weekend Crash Course", January 2002, ISBN: > 0764549014 > (I'm a little worried about the prevalence of ".. in a weekend" style > books - what quality of database are people building after learning the > language in a weekend?) > > > Note that during my quick search for books about "SQL", about half of > the returns were books about Microsoft SQL Server. I guess MS-SQL > administrators have lots of reading time :) > > That list will most likely take me 12 months or more to read through > myself. Anyone care to guess what version of PostgreSQL will be > "current" in December 2004? > > Regards > Alex Satrapa > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Robert Treat wrote: > one thing I noticed about your list, it focuses a lot on sql. IMO this is a > mistake, try to put more focus on relational theory, something that sql wont > teach you. >>9) Alex Kiregel & Boris M. Trukhnov, "SQL Bible", April 2003, ISBN: >>0764525840 In that case, I'll try to find a copy of this book to review - it covers a lot more than just SQL. Then here's a list of "relational data model" hits at Barnes and Noble, that aren't reviewed on the PostgreSQL site already: 1) Terry Halpin & T. A. Halpin, "Information Modeling and Relational Databases: From Conceptual Analysis to Logical Design", April 2001, ISBN: 1558606726 2) Isolina Salgado, "Relational Database Design: A Practical Approach", September 1999, ISBN: 0758035586 3) Jan L. Harrington, "Relational Database Design Clearly Explained", May 2002, ISBN: 1558608206 From the reviews I've read on the B&N site, (3) is the one I'll probably start with. I'm amazed by the price difference between the USA ($US40 at B&N) and Australia ($AU101 at Dymocks)... here we go on the consumer-driven extinction of Australian bookshops... Alex Satrapa Lintelsys
Quoting Shridhar Daithankar <shridhar_daithankar@myrealbox.com>: > On Sunday 28 December 2003 11:15, D. Dante Lorenso wrote: > > The only SQL customizations that MySQL has that I really miss in > PostgreSQL > > are the commands: > > > > SHOW DATABASES; > > \l > > > SHOW TABLES; > > \dt > > > DESC table; > > \d tablename > > > > > That was ubber simple to do in MySQL. To this day, I have trouble with > > that in PostgreSQL. I'm constantly doing: > > > > psql> \? > > psql> help; > > ERROR: syntax error at or near "help" at character 1 > > psql> \h > > ... > > * damnit, that's not it...* > > psql> \? > > psql> \d > > * ok, now which flag do I use for tables vs functions..etc?* > > \df for functions and \dt for tables. > > Problem is psql is unique though very powerful. I need to use oracle's > sql-plus on HP-UX at times(Otherwise I crawl back to TOAD) and I don't think > > it is nowhere near to psql. > > or may be I play with postgresql more than oracle..:-) anyways > > > I finally figure it out, I just end up forgetting again later. I still > > have no clue how I'd find the same data without using psql. In MySQL > > I can run those queries from PHP, PERL...etc. I know you can find that > > data in system tables in PostgreSQL, but I don't wanna muck around with > > all that. I just wanna do something as simple as MySQL. > > Well, actually I would say it is great way of learning postgresql internals. > > There is a switch -E to psql which shows you queries sent to server for each > > command you provide. > > Problem with mysql is the approach is easy to start with but adding those > command in your standard list of SQL commands falls out on standard > compliance and maintainability. > > Another post on this thread mentioned postgresql should run against oracle. > Sole reason postgresql v/s mysql debate should exist is to provide > comparision in feasibility study. The hurdles you mentioned are true but that > > are just part of bit steeper learning curve of a standard way of doing > things.. > > Shridhar This is what I don't get. Why do people thing learn PG is going to be like learning MySQL in the first place? Because its OSS?? I certainly hope not. This is apples to oranges. I read someone say the documentation was "light" too. I'm not sure what that meant but I looked for at the 3 inch doubled side binded of my 7.3.2 docs- admin,user &,programmer- its as big as my J2EE binder. Not very scientific I know :) Seriously though, when people indicate PG is "hard", I hear, "if it was easy everone would be doing it". -$0.02 > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Keith C. Perry, MS E.E. Director of Networks & Applications VCSN, Inc. http://vcsn.com ____________________________________ This email account is being host by: VCSN, Inc : http://vcsn.com
I agree with you (speaking as a newbie) I don't believe any dumbing down is necessary at all. I DO believe however that a decent introduction to the more important concepts (Triggers, Fkeys, Stored Proc, Views) that people from lesser systems (MySQL, Access) may not be familiar with. What they do, how they help, and why they are generally a good thing. This intro would probably fit either in the tutorial or in the User Guide.
Don't hold peoples hand for them, but at least provide them with the tools they need to make an educated decision.
T.
Shridhar Daithankar wrote:
Don't hold peoples hand for them, but at least provide them with the tools they need to make an educated decision.
T.
Shridhar Daithankar wrote:
On Monday 29 December 2003 12:47, Tom Lane wrote:Shridhar Daithankar <shridhar_daithankar@myrealbox.com> writes:That is right. but that fact remains that postgresql documentation is just sufficient. If you read the manual and follow it religously to comma and fullstop, it tells you everythings. But it certainly isn't a place where you can glance over it and get hang of it.This is surely true, and I've not seen anyone denying it. The peopleWell, for newbies to postgresql, let's state this fact upfront and not make them discover it..:-)who are doing development are, um, not strong at documentation (I include myself here). What we need are some folks to step up and improve the documentation --- and then maintain it in the face of future changes. Any volunteers out there? This is an open-source project after all, and that means "scratch your own itch" among other things...If you ask me, let's not do that. Not at least on a grand scale. Isolated areas are OK on case by case basis.. I regualrly use development build documentation from developers.postgresql.org and I have seen the documentation in source code. In my view, postgresql developers do document it very clearly whenever required. If we dilute the documentation too much, that will make things simpler initially but that will simply create a maintainance nightmare as one has to maintain much larger amount of documentation. And once you get used to precise style of postgresql documentation, going back to anything else is a pain. ( MSDN.. I scream at nights.... but I digress). IMO documentation of postgresql is fine overall. What we need to do is. 1. State upfront that this is not handholding. It will make lots of things easier and offload work of expanding documents given limited human resources working on the project. A disclaimer is far easier to maintain than a manual..:-) And it will prepare anybody for upcoming hardships..:-) 2. Document and reuse it. Personally I would like to see responses on general and oter such list as URLs. If we answer it repeatedly, let's document it and point the people to them. Let them dig around 3-4 URLs around it and they will have islands of enlightenments. Over the period, these island will merge in a great landscape..:-) Just a thought.. Shridhar P.S. If somebody thinks I can not imagine how a newbie feels, I will agree. But looking back, dumbing down anything is not good in long term..an experience that is ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
By that logic then, we can probably ditch the PG Tutorial altogether and provide a quick ref card of PG commands and keywords, with a few pages on how PG is different should be plenty. The bisggest problem that I faced when moving to PG was the complete lack of any cetralised information source for this information. Sure there are tutorials on the web, first track them down, then convert their use to PG then collate them, then make some sense of it all. This is the kind of aloofness that I have mentioned previously, just because it doesn't belong, doesn't mean it's not needed, and it only needs to be written once. Although I know some of the concepts and I'm beginning to grock them, I'm still trying to collate enough to satisfy my needs. Assuming yo *do* want to grow the PG community and attract people from other systems, the easier the transition for them, the less likely they are to look elsewhere for something that appears easier. Easier doesn't always mean easier to use, sometimes it can mean easier to get to grips with. T. Shridhar Daithankar wrote: >For one thing, these thing do not belong to postgresql documentation. > >But I don't believe there is shortage of material on these topics on web and >in print. > >However if you are refering to explaining these things, w.r.t. postgresql, I >would be more than happy to churn out some extremely basic tutorials. > >Can you tell us what all you need? Rephrasing, if you know these(and some >other) concpets by now, what all you missed while learning postgresql? > >It may sound like stupid question but unlearning things out of imagination is >not easy...:-) > > Shridhar > > > >
Shridhar Daithankar <shridhar_daithankar@myrealbox.com> writes:
> That is right. but that fact remains that postgresql documentation is just
> sufficient. If you read the manual and follow it religously to comma and
> fullstop, it tells you everythings. But it certainly isn't a place where you
> can glance over it and get hang of it.
This is surely true, and I've not seen anyone denying it. The people
who are doing development are, um, not strong at documentation (I
include myself here). What we need are some folks to step up and
improve the documentation --- and then maintain it in the face of future
changes. Any volunteers out there? This is an open-source project
after all, and that means "scratch your own itch" among other things...
regards, tom lane
Apologies, try this link instead: http://miami.int.gu.edu.au/dbs/7016/a85397/state27a.htm#2067717 The previous one required you to be signed with technet - the one above should be viewable by all. John John Sidney-Woollett said: > I agree with most of this sentiment. Even knowing SQL and RDBMs reasonably > well, there is still a significant effort involved in moving from another > RDBMS (in my case Oracle) to postgres. > > The postgres docs provide much all the detail (in a very concise form). > The hard part is putting all the different pieces together to solve some > problem. In fact, this is where the postgres users list is so good, > because the support and feedback from it is excellent. > > Contrast this page from the docs (for the update statement), > http://www.postgres.org/docs/current/interactive/sql-update.html with > Oracle's (for 8.1.7) > http://download-west.oracle.com/docs/cd/A87860_01/doc/server.817/a85397/state27a.htm#2067717 > > Some might feel that much of the information is redundant or bloat. I > disagree - you get a feel for what is possible as well as links to other > commands, subtopics, and concept explanations. > > Someone commented that maintaining docs (of this sort) would be too hard - > I disagree. Many of the commands are *mostly* implementation agnostic, and > the initial docs would require siginificant effort to build, but should > only require moderate maintenance as features are added or modified. > > Just my two cents (again). > > John Sidney-Woollett > > ps And yes, I would be willing to help once my current project is > complete... > > Tony said: >> By that logic then, we can probably ditch the PG Tutorial altogether and >> provide a quick ref card of PG commands and keywords, with a few pages >> on how PG is different should be plenty. >> >> The bisggest problem that I faced when moving to PG was the complete >> lack of any cetralised information source for this information. Sure >> there are tutorials on the web, first track them down, then convert >> their use to PG then collate them, then make some sense of it all. >> This is the kind of aloofness that I have mentioned previously, just >> because it doesn't belong, doesn't mean it's not needed, and it only >> needs to be written once. Although I know some of the concepts and I'm >> beginning to grock them, I'm still trying to collate enough to satisfy >> my needs. >> >> Assuming yo *do* want to grow the PG community and attract people from >> other systems, the easier the transition for them, the less likely they >> are to look elsewhere for something that appears easier. Easier >> doesn't always mean easier to use, sometimes it can mean easier to get >> to grips with. >> >> T. >> >> Shridhar Daithankar wrote: >> >>>For one thing, these thing do not belong to postgresql documentation. >>> >>>But I don't believe there is shortage of material on these topics on web >>> and >>>in print. >>> >>>However if you are refering to explaining these things, w.r.t. >>> postgresql, I >>>would be more than happy to churn out some extremely basic tutorials. >>> >>>Can you tell us what all you need? Rephrasing, if you know these(and >>> some >>>other) concpets by now, what all you missed while learning postgresql? >>> >>>It may sound like stupid question but unlearning things out of >>> imagination is >>>not easy...:-) >>> >>> Shridhar >>> >>> >>> >>> >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 7: don't forget to increase your free space map settings >> > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
I agree with most of this sentiment. Even knowing SQL and RDBMs reasonably well, there is still a significant effort involved in moving from another RDBMS (in my case Oracle) to postgres. The postgres docs provide much all the detail (in a very concise form). The hard part is putting all the different pieces together to solve some problem. In fact, this is where the postgres users list is so good, because the support and feedback from it is excellent. Contrast this page from the docs (for the update statement), http://www.postgres.org/docs/current/interactive/sql-update.html with Oracle's (for 8.1.7) http://download-west.oracle.com/docs/cd/A87860_01/doc/server.817/a85397/state27a.htm#2067717 Some might feel that much of the information is redundant or bloat. I disagree - you get a feel for what is possible as well as links to other commands, subtopics, and concept explanations. Someone commented that maintaining docs (of this sort) would be too hard - I disagree. Many of the commands are *mostly* implementation agnostic, and the initial docs would require siginificant effort to build, but should only require moderate maintenance as features are added or modified. Just my two cents (again). John Sidney-Woollett ps And yes, I would be willing to help once my current project is complete... Tony said: > By that logic then, we can probably ditch the PG Tutorial altogether and > provide a quick ref card of PG commands and keywords, with a few pages > on how PG is different should be plenty. > > The bisggest problem that I faced when moving to PG was the complete > lack of any cetralised information source for this information. Sure > there are tutorials on the web, first track them down, then convert > their use to PG then collate them, then make some sense of it all. > This is the kind of aloofness that I have mentioned previously, just > because it doesn't belong, doesn't mean it's not needed, and it only > needs to be written once. Although I know some of the concepts and I'm > beginning to grock them, I'm still trying to collate enough to satisfy > my needs. > > Assuming yo *do* want to grow the PG community and attract people from > other systems, the easier the transition for them, the less likely they > are to look elsewhere for something that appears easier. Easier > doesn't always mean easier to use, sometimes it can mean easier to get > to grips with. > > T. > > Shridhar Daithankar wrote: > >>For one thing, these thing do not belong to postgresql documentation. >> >>But I don't believe there is shortage of material on these topics on web >> and >>in print. >> >>However if you are refering to explaining these things, w.r.t. >> postgresql, I >>would be more than happy to churn out some extremely basic tutorials. >> >>Can you tell us what all you need? Rephrasing, if you know these(and some >>other) concpets by now, what all you missed while learning postgresql? >> >>It may sound like stupid question but unlearning things out of >> imagination is >>not easy...:-) >> >> Shridhar >> >> >> >> > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings >
Quoting Shridhar Daithankar <shridhar_daithankar@myrealbox.com>: > On Monday 29 December 2003 12:47, Tom Lane wrote: > > Shridhar Daithankar <shridhar_daithankar@myrealbox.com> writes: > > > That is right. but that fact remains that postgresql documentation is > > > just sufficient. If you read the manual and follow it religously to > comma > > > and fullstop, it tells you everythings. But it certainly isn't a place > > > where you can glance over it and get hang of it. > > > > This is surely true, and I've not seen anyone denying it. The people > > Well, for newbies to postgresql, let's state this fact upfront and not make > them discover it..:-) > > > who are doing development are, um, not strong at documentation (I > > include myself here). What we need are some folks to step up and > > improve the documentation --- and then maintain it in the face of future > > changes. Any volunteers out there? This is an open-source project > > after all, and that means "scratch your own itch" among other things... > > If you ask me, let's not do that. Not at least on a grand scale. Isolated > areas are OK on case by case basis.. > > I regualrly use development build documentation from > developers.postgresql.org > and I have seen the documentation in source code. In my view, postgresql > developers do document it very clearly whenever required. > > If we dilute the documentation too much, that will make things simpler > initially but that will simply create a maintainance nightmare as one has to > > maintain much larger amount of documentation. > > And once you get used to precise style of postgresql documentation, going > back > to anything else is a pain. ( MSDN.. I scream at nights.... but I digress). > > IMO documentation of postgresql is fine overall. What we need to do is. > > 1. State upfront that this is not handholding. > > It will make lots of things easier and offload work of expanding documents > given limited human resources working on the project. A disclaimer is far > easier to maintain than a manual..:-) > > And it will prepare anybody for upcoming hardships..:-) > > 2. Document and reuse it. > > Personally I would like to see responses on general and oter such list as > URLs. If we answer it repeatedly, let's document it and point the people to > them. Let them dig around 3-4 URLs around it and they will have islands of > enlightenments. Over the period, these island will merge in a great > landscape..:-) > > Just a thought.. > > Shridhar > > P.S. If somebody thinks I can not imagine how a newbie feels, I will agree. > But looking back, dumbing down anything is not good in long term..an > experience that is > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > Shridhar, I tend to agree with you. I personally think the docs are very good and have the techical depth warranted for a product like PostgreSQL. On the other hand for the ad & m (advocacy and marketing) side of things. I'm betting some clearly labelled tutorials/guide next to the disclaimer about the the main docs be more of a reference would appease those who might be a bit green to a product of PG breadth and depth (heck I still think I'm in the category sometimes). 'bout two weeks ago there was another thread where certificating/training et al were discussed and one of the things that I had mentioned was that in that regard, we should probably have more tutorial/guide based on real world scenarios available on techdocs. Although I don't think I qualified to write for the main docs, I definitely can contribute to the techdocs in the manner I just mentioned. Matter a fact, I finally finish my first one "Using PostgreSQL for Domino 6 RDBMS Backends". I'm doing the final read now so hopefully I can get it over to Robert for posting. Perhaps the "newer" folks on the list could tell us what type of guides they want to see. I'm sure someone has a wish list somewhere. -- Keith C. Perry, MS E.E. Director of Networks & Applications VCSN, Inc. http://vcsn.com ____________________________________ This email account is being host by: VCSN, Inc : http://vcsn.com
Tony <tony@unihost.net> writes:
> ... I DO believe however that a decent introduction to
> the more important concepts (Triggers, Fkeys, Stored Proc, Views) that
> people from lesser systems (MySQL, Access) may not be familiar with.
> What they do, how they help, and why they are generally a good thing.
> This intro would probably fit either in the tutorial or in the User Guide.
Many of these subjects already *are* covered in the Tutorial. Just
looking in the 7.4 table of contents, I see
3. Advanced Features
3.1. Introduction
3.2. Views
3.3. Foreign Keys
3.4. Transactions
3.5. Inheritance
3.6. Conclusion
The discussions are skimpy and could use fleshed out a little, no doubt.
(Anyone who wants to contribute material is surely welcome to.)
BTW, there is a separate mailing list pgsql-docs for those who want to
work on documentation.
regards, tom lane
On Dec 29, 2003, at 12:15, Tony wrote:
> I already had in the first post I replied to, but at the risk of
> sounding redundant, I'll say it again.
>
> Views: When I came to PG I didn't know what they were, saw no point
> to them (still don't) why do you need a function to provide details of
> a query when a more complicated query gives the same data? Are they
> designed for people who don't like to type long queries?
This is a standard database concept. You can do lots of things with
Views. For example, you can create a subview of a table that only
reveals a few columns and provide access to that view to a specific
group of people who can't see the whole table. You can also use them
as an abstraction layer for applications (i.e. we have a DB guy who
makes minor schema changes regularly and maintains the actual queries
our application uses without us necessarily having to know).
> Stored Procedures: Sounds good in principle, but in what ways can I
> benefit most (I understand this now) at the time of moving to PG, I
> couldn't see the difference between writing my code in an a Stored
> Proc or an API.
This is a standard database concept. They're useful for triggers
among other things. We don't use them a lot in our application
anymore, but they can be useful if there's a lot of complicated DB
interaction required for a specific thing to occur when it doesn't
require a great deal of input.
> Triggers: make perfect sense now, but didn't used to when I didn't
> know what they were.
Right, a standard database concept.
> This isn't definitive list but more of a flavour of the obstacles I
> hit when I first met PG. If I hadn't persevered (and many may not)
> I'd have ended up with a PG server full of DBs designed and built as
> if they were on a MySQL server.
>
> Yes, the topics are covered fleetingly in the tutorial, but do such
> important topics only warrant 3 pages of text between the lot of
> them? It's great that the subjects are present, but it seems to be in
> more of a kind of "Whilst We're on the Subject of Databases" kind of
> passing comment.
>
> Maybe I'm asking for the Moon on a Stick, but it didn't feel like I
> was :)
The problem you're describing isn't ``how can we provide documentation
that helps people understand postgres better,'' but ``how can we
provide documentation to teach people database concepts.''
It might be nice to provide a really nice SQL and RDBMS concept
reference, but it would be beyond the scope of product documentation
(somewhat).
Perhaps another documentation set for unteaching mySQL might be nice
as well. They're taking care of some of that themselves (by
implementing a lot of the things they used to say were unimportant
crutches for lazy programmers), but a lot of it still resonates. I get
annoyed every time I read someone suggesting that transactions aren't
required for most applications, or that subqueries are for lazy people
who can't do loops in code or whatever.
--
SPY My girlfriend asked me which one I like better.
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________
"Joshua D. Drake" <jd@commandprompt.com> writes:
> How about just a "Getting Started with PostgreSQL" guide... Python
> is like this. They have the "real" documentation but they also have a
> introductory tutorial. We could have a brief document (100 pages or
> less) that talks about the basic concepts of PostgreSQL...
How would this differ from the existing Tutorial?
regards, tom lane
Quoting Tom Lane <tgl@sss.pgh.pa.us>: > Tony <tony@unihost.net> writes: > > ... I DO believe however that a decent introduction to > > the more important concepts (Triggers, Fkeys, Stored Proc, Views) that > > people from lesser systems (MySQL, Access) may not be familiar with. > > What they do, how they help, and why they are generally a good thing. > > This intro would probably fit either in the tutorial or in the User Guide. > > Many of these subjects already *are* covered in the Tutorial. Just > looking in the 7.4 table of contents, I see > > 3. Advanced Features > 3.1. Introduction > 3.2. Views > 3.3. Foreign Keys > 3.4. Transactions > 3.5. Inheritance > 3.6. Conclusion > > The discussions are skimpy and could use fleshed out a little, no doubt. > (Anyone who wants to contribute material is surely welcome to.) > > BTW, there is a separate mailing list pgsql-docs for those who want to > work on documentation. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > This concerns me. This is the second time recently someone has said something is NOT documented and it it turn out it is. So my question is (no offense to anyone) are the web sites not "clear" enough to find information quickly or are people just being lax/lazy when they are searching. -- Keith C. Perry, MS E.E. Director of Networks & Applications VCSN, Inc. http://vcsn.com ____________________________________ This email account is being host by: VCSN, Inc : http://vcsn.com
Tony wrote: > I already had in the first post I replied to, but at the risk of > sounding redundant, I'll say it again. > > Views: When I came to PG I didn't know what they were, saw no point > to them (still don't) why do you need a function to provide details of > a query when a more complicated query gives the same data? Are they > designed for people who don't like to type long queries? Personally I find views useful because I can hide the details of the database internals from the application. Hence they provide an "interface" level abstraction. This is very important if you want to isolate the database and application development. I've never seen that stated in a document. > Stored Procedures: Sounds good in principle, but in what ways can I > benefit most (I understand this now) at the time of moving to PG, I > couldn't see the difference between writing my code in an a Stored > Proc or an API. I don't understand what you mean here/ > > > This isn't definitive list but more of a flavour of the obstacles I > hit when I first met PG. If I hadn't persevered (and many may not) > I'd have ended up with a PG server full of DBs designed and built as > if they were on a MySQL server. Yep - I see that alot.
I already had in the first post I replied to, but at the risk of sounding redundant, I'll say it again.
Views: When I came to PG I didn't know what they were, saw no point to them (still don't) why do you need a function to provide details of a query when a more complicated query gives the same data? Are they designed for people who don't like to type long queries?
Stored Procedures: Sounds good in principle, but in what ways can I benefit most (I understand this now) at the time of moving to PG, I couldn't see the difference between writing my code in an a Stored Proc or an API.
Triggers: make perfect sense now, but didn't used to when I didn't know what they were.
This isn't definitive list but more of a flavour of the obstacles I hit when I first met PG. If I hadn't persevered (and many may not) I'd have ended up with a PG server full of DBs designed and built as if they were on a MySQL server.
Yes, the topics are covered fleetingly in the tutorial, but do such important topics only warrant 3 pages of text between the lot of them? It's great that the subjects are present, but it seems to be in more of a kind of "Whilst We're on the Subject of Databases" kind of passing comment.
Maybe I'm asking for the Moon on a Stick, but it didn't feel like I was :)
T.
Shridhar Daithankar wrote:
Views: When I came to PG I didn't know what they were, saw no point to them (still don't) why do you need a function to provide details of a query when a more complicated query gives the same data? Are they designed for people who don't like to type long queries?
Stored Procedures: Sounds good in principle, but in what ways can I benefit most (I understand this now) at the time of moving to PG, I couldn't see the difference between writing my code in an a Stored Proc or an API.
Triggers: make perfect sense now, but didn't used to when I didn't know what they were.
This isn't definitive list but more of a flavour of the obstacles I hit when I first met PG. If I hadn't persevered (and many may not) I'd have ended up with a PG server full of DBs designed and built as if they were on a MySQL server.
Yes, the topics are covered fleetingly in the tutorial, but do such important topics only warrant 3 pages of text between the lot of them? It's great that the subjects are present, but it seems to be in more of a kind of "Whilst We're on the Subject of Databases" kind of passing comment.
Maybe I'm asking for the Moon on a Stick, but it didn't feel like I was :)
T.
Shridhar Daithankar wrote:
On Monday 29 December 2003 15:25, Tony wrote:By that logic then, we can probably ditch the PG Tutorial altogether and provide a quick ref card of PG commands and keywords, with a few pages on how PG is different should be plenty. The bisggest problem that I faced when moving to PG was the complete lack of any cetralised information source for this information. Sure there are tutorials on the web, first track them down, then convert their use to PG then collate them, then make some sense of it all. This is the kind of aloofness that I have mentioned previously, just because it doesn't belong, doesn't mean it's not needed, and it only needs to be written once. Although I know some of the concepts and I'm beginning to grock them, I'm still trying to collate enough to satisfy my needs. Assuming yo *do* want to grow the PG community and attract people from other systems, the easier the transition for them, the less likely they are to look elsewhere for something that appears easier. Easier doesn't always mean easier to use, sometimes it can mean easier to get to grips with.*Sigh*.. You just read my first remark which you could have bypassed but anyways.. What do you think of offer I made? I was slightly disappointed to see that you missed it.. I am not removing my original message. Please read and let me know what do you think..Shridhar Daithankar wrote:For one thing, these thing do not belong to postgresql documentation. But I don't believe there is shortage of material on these topics on web and in print. However if you are refering to explaining these things, w.r.t. postgresql, I would be more than happy to churn out some extremely basic tutorials. Can you tell us what all you need? Rephrasing, if you know these(and some other) concpets by now, what all you missed while learning postgresql? It may sound like stupid question but unlearning things out of imagination is not easy...:-)Shridhar ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)