473,889 Members | 1,426 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Is my MySQL Gaining ?

Dear all,

Their was a huge rore about MySQL recently for something in java functions
now theirs one more

http://www.mysql.com/doc/en/News-5.0.x.html

Does this concern anyone.

What I think is PostgreSQL would have less USP's (Uniqe Selling Points
though we dont sell) now.

What do you think yes we PostgreSQL users need some introspection.

Regards,
Vishal Kashyap.

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05
175 11562
Bruno Wolff III wrote:
Once you know where to look for stuff it isn't that hard to find things.
Yes, but what happens where you don't know where to look for stuff?
This is one of the advantages of reading through the whole manual once
to get an idea of whats there.

Sure, but who has time to read through a whole manual first? No system I
ever learned had me do that.
When I need to look things up for Postgres I use a local copy of the web
based documentation.

A good idea. But If you work for different locations (home, client's
office, office), then that becomes redundant. Besides I would be
responsible for syncing the manual from PG to each location. Besides, a
local copy would not usually have a search engine built in.
I don't like this. It will make scrolling through a group of related
functions harder. Name anchors can be used to allow links directly to
functions.

Nope. I disagree with this one. It makes finding stuff easier if you
type "nextval()" into a search engine, and it takes you directly to the
nextval page.
Do you see these two points as applying to only the copy of the
documentatio n on the Postgres web site, or do you see this being distributed
either with the database (as the current documentation is) or as
a separate item (like some of the clients are)?

In this case, documentation on the website should always be primary.
Almost anyone working on modern software is always connected to the
internet. A static copy of the interactive documentation can always be
distributed with the software. But do many people even refer to the
included documentation? To be honest, I dont. The documentation in psql
(eg: \h COPY) is as far as i'll go, the next step in the main site, or
google. Why rely on documentation on your hard disk that will get out of
date soon anyway?

- Ericson Smith
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

Nov 12 '05 #101
Hmm... I havn't heard anything about this.

Ericson Smith wrote:
....
They might be more inclined to, since they are dropping MySQL from
inclusion in PHP.


....

From what I can tell they are not supplying the client libraries anymore. You have to have the libraries installed before you can build support for MySQL. They are not getting rid of support for MySQL, you will just need to supply your own libraries, which is what you have to do to get PostgreSQL support as well.

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #102
As far as the documentation goes, you know that its bad when you have to
lookup SQL examples on the MySQL site to use with Postgresql. I'm no
SQL (never read fully my "SQL for Smarties" book) guru, so every little
bit helps. If we have a great (not just good, or adequate) documentation
site, then the uptake will be better. So why not let pool some funds
from members of the list and get some professional help? My wallet is
open and ready.

Warmest regards,
Ericson Smith
Tracking Specialist/DBA
+-----------------------+----------------------------+
| http://www.did-it.com | "When I'm paid, I always |
| er**@did-it.com | follow the job through. |
| 516-255-0500 | You know that." -Angel Eyes|
+-----------------------+----------------------------+

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #103
On Mon, Dec 29, 2003 at 16:18:38 -0500,
Ericson Smith <er**@did-it.com> wrote:
Bruno Wolff III wrote:
Once you know where to look for stuff it isn't that hard to find things.
Yes, but what happens where you don't know where to look for stuff?


Then I look though the table of contents to see what sections might
be relevant and try them in an order based on which I think are most
likely to give me what I want.
This is one of the advantages of reading through the whole manual once
to get an idea of whats there.

Sure, but who has time to read through a whole manual first? No system I
ever learned had me do that.


This I find hard to believe. Reading through the manual (with some skimming)
before doing a lot of work will probably end up saving you time in the long
run.
When I need to look things up for Postgres I use a local copy of the web
based documentation.

A good idea. But If you work for different locations (home, client's
office, office), then that becomes redundant. Besides I would be
responsible for syncing the manual from PG to each location. Besides, a
local copy would not usually have a search engine built in.


I installed copies of the documentation at home and work while installing
the server. However, I don't use Postgres when not at home or work, so
the client example doesn't apply to me. In some cases having it on your
laptop would be useful.
I don't like this. It will make scrolling through a group of related
functions harder. Name anchors can be used to allow links directly to
functions.

Nope. I disagree with this one. It makes finding stuff easier if you
type "nextval()" into a search engine, and it takes you directly to the
nextval page.


Maybe if you are using google where you won't get placed at the relevant
part of the page you get pointed to. With a custom search engine, you
could reference directly to the function's entry within a page.
Do you see these two points as applying to only the copy of the
documentatio n on the Postgres web site, or do you see this being
distributed
either with the database (as the current documentation is) or as
a separate item (like some of the clients are)?

In this case, documentation on the website should always be primary.
Almost anyone working on modern software is always connected to the
internet. A static copy of the interactive documentation can always be
distributed with the software. But do many people even refer to the
included documentation? To be honest, I dont. The documentation in psql
(eg: \h COPY) is as far as i'll go, the next step in the main site, or
google. Why rely on documentation on your hard disk that will get out of
date soon anyway?


Because it matches the version installed on that machine. When using
the documentation on the Postgres site, you need to be concerned about
looking at the correct copy unless you are mostly running the latest
release.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

Nov 12 '05 #104
On Mon, Dec 29, 2003 at 02:21:27PM -0700, Guy Fraser wrote:
Ericson Smith wrote:
They might be more inclined to, since they are dropping MySQL from
inclusion in PHP.

From what I can tell they are not supplying the client libraries
anymore. You have to have the libraries installed before you can build
support for MySQL. They are not getting rid of support for MySQL, you
will just need to supply your own libraries, which is what you have to
do to get PostgreSQL support as well.


Hmm... I havn't heard anything about this.


http://www.php.net/mysql

"In PHP 5, MySQL is no longer enabled by default, nor is the MySQL
library bundled with PHP. Read this FAQ for details on why."

Here's the FAQ in question:

http://www.php.net/faq.databases#faq...ses.mysql.php5

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #105
On Mon, Dec 29, 2003 at 16:28:54 -0500,
Ericson Smith <er**@did-it.com> wrote:
As far as the documentation goes, you know that its bad when you have to
lookup SQL examples on the MySQL site to use with Postgresql. I'm no
SQL (never read fully my "SQL for Smarties" book) guru, so every little
bit helps. If we have a great (not just good, or adequate) documentation
site, then the uptake will be better. So why not let pool some funds
from members of the list and get some professional help? My wallet is
open and ready.


That kind of question will generally not be postgres specific (unless
you are asking about syntax which is compactly described for each
SQL command). It might be better to provide references to web sites
that provide general information about SQL (if there are any good ones),
rather than to spend a lot of resources trying to teach people generic
stuff about SQL and RDBMS.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

Nov 12 '05 #106
I guess my point is that; should we be pushing to keep the current
documentation, or should we be looking to improve it?

Should we be moving towards short concise pages describing a single
issue that is robustly interlinked, or should we be looking at longer
pages anchored by HTML text that if discovered by a search engine makes
it actually harder to find information since we have to read through the
whole page?

Is it better to catalog 1000 specific pages about 1000 things, or 100
pages about 10 things? Which system would bring a user to the
information they needed faster, if a search engine that positioned users
at the *top* of a document were employed? If presented with a PDF file
or an HTML document on the web, which would you use (consider that you
need the information now, not an hour later)?

Today, we use search engines as the starting point on the web (except
for bookmarked or otherwise memorized pages). Why build systems that
breaks that paradigm, or take advantage of it insufficiently?

Don't get me wrong, I am glad that some documentation is there, but as
many other posters have said, it needs to be better.

- Ericson

Bruno Wolff III wrote:
On Mon, Dec 29, 2003 at 16:18:38 -0500,
Ericson Smith <er**@did-it.com> wrote:

Bruno Wolff III wrote:
Once you know where to look for stuff it isn't that hard to find things.


Yes, but what happens where you don't know where to look for stuff?


Then I look though the table of contents to see what sections might
be relevant and try them in an order based on which I think are most
likely to give me what I want.
This is one of the advantages of reading through the whole manual once
to get an idea of whats there.

Sure, but who has time to read through a whole manual first? No system I
ever learned had me do that.


This I find hard to believe. Reading through the manual (with some skimming)
before doing a lot of work will probably end up saving you time in the long
run.
When I need to look things up for Postgres I use a local copy of the web
based documentation.

A good idea. But If you work for different locations (home, client's
office, office), then that becomes redundant. Besides I would be
responsible for syncing the manual from PG to each location. Besides, a
local copy would not usually have a search engine built in.


I installed copies of the documentation at home and work while installing
the server. However, I don't use Postgres when not at home or work, so
the client example doesn't apply to me. In some cases having it on your
laptop would be useful.
I don't like this. It will make scrolling through a group of related
functions harder. Name anchors can be used to allow links directly to
functions.

Nope. I disagree with this one. It makes finding stuff easier if you
type "nextval()" into a search engine, and it takes you directly to the
nextval page.


Maybe if you are using google where you won't get placed at the relevant
part of the page you get pointed to. With a custom search engine, you
could reference directly to the function's entry within a page.
Do you see these two points as applying to only the copy of the
documentatio n on the Postgres web site, or do you see this being
distribute d
either with the database (as the current documentation is) or as
a separate item (like some of the clients are)?


In this case, documentation on the website should always be primary.
Almost anyone working on modern software is always connected to the
internet. A static copy of the interactive documentation can always be
distributed with the software. But do many people even refer to the
included documentation? To be honest, I dont. The documentation in psql
(eg: \h COPY) is as far as i'll go, the next step in the main site, or
google. Why rely on documentation on your hard disk that will get out of
date soon anyway?


Because it matches the version installed on that machine. When using
the documentation on the Postgres site, you need to be concerned about
looking at the correct copy unless you are mostly running the latest
release.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

Nov 12 '05 #107
On Mon, Dec 29, 2003 at 16:45:40 -0500,
Ericson Smith <er**@did-it.com> wrote:

Today, we use search engines as the starting point on the web (except
for bookmarked or otherwise memorized pages). Why build systems that
breaks that paradigm, or take advantage of it insufficiently?


That may be how you do things, but I don't know that everyone does that.
I use search engines for some stuff. For postgres I run a doc command
that run lynx and points to a local documentation list with about a half
dozen documentation sets I use commonly. I follow the Postgres link
to get to the Postgres table of contents and then go to which ever section
has the information I want.

I think you are expecting a bit much out of general search engines if you
expect them to figure the correct part of the documentation to return.
If you have to go back and forth with the search engine, you are probably
better off using the table of contents.

Scrolling down large pages even when the search engine doesn't point you
to the nearest anchor to what you are looking for isn't that slow.
If the page is really big, you can do a text search within the page.

I think it is more important for the documentation to be easily readable than
for it to be designed so that searched for information will always be
near the top of the returned page.

P.S. Do you think anyone at Google has thought of adding anchors to their
returned URLs to get you closer to the terms you were searching for?

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #108
Quoting Ericson Smith <er**@did-it.com>:
Bruno Wolff III wrote:
Once you know where to look for stuff it isn't that hard to find things.

Yes, but what happens where you don't know where to look for stuff?


Fair enough- the search engine definitely are problematic and the main site
probably needs to be reorganized to clearly identify the most important URLs.
This is one of the advantages of reading through the whole manual once
to get an idea of whats there.

Sure, but who has time to read through a whole manual first? No system I
ever learned had me do that.


I'm not a very versused in Oracle but I know that when I used to spec hardware
for them the company I was with pretty much wanted us to read everything we
could get our hands on.

People absolutely should "read" the manual in at least 2 passes. The 1st to get
and overview and feel for how the documentation is put together and a 2nd
(probably on some specific topics first) to get the nuts and bolts how to do
something. I personally don't feel we should like Bruno said early people NOT
reading the manual. Saying you have not had to do that before is not really a
reason. Its counter-productive in the long run.
When I need to look things up for Postgres I use a local copy of the web
based documentation.

A good idea. But If you work for different locations (home, client's
office, office), then that becomes redundant. Besides I would be
responsible for syncing the manual from PG to each location. Besides, a
local copy would not usually have a search engine built in.


I don't see how that is redundant unless you mean, you'd have to download things
to multiple sites. You're right that is not the way to go. I think most people
get these days that the provided documentation is snapshot and will change but I
for one would not want to be online while I was riding the train to NY to look
up something that I could have cached locally. The website is the master and
the freedom to "sync" (e.g. download) is your choice.
I don't like this. It will make scrolling through a group of related
functions harder. Name anchors can be used to allow links directly to
functions.

Nope. I disagree with this one. It makes finding stuff easier if you
type "nextval()" into a search engine, and it takes you directly to the
nextval page.


I'm not sure how the search function works but I don't see how these two things
are mutually exclusive. One function per page would definitely take the context
away from where and how you might use a certain functions. I would think in the
interest of orderly presentation we would want to group things while still being
able to go directly to the function in question.

(I've never have a problem searching the documents actually. I think the search
engine there is quite good since it hit multiple versions.)
Do you see these two points as applying to only the copy of the
documentatio n on the Postgres web site, or do you see this being

distributed
either with the database (as the current documentation is) or as
a separate item (like some of the clients are)?

In this case, documentation on the website should always be primary.
Almost anyone working on modern software is always connected to the
internet. A static copy of the interactive documentation can always be
distributed with the software. But do many people even refer to the
included documentation? To be honest, I dont. The documentation in psql
(eg: \h COPY) is as far as i'll go, the next step in the main site, or
google. Why rely on documentation on your hard disk that will get out of
date soon anyway?

- Ericson Smith

--
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

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #109
I hate to keep saying, "yes, but...". But!

Where are we going with this? Sure we are grizzled developers, who use
lynx (links is my favourite), emacs and all that stuff to read our docs,
rsync or wget to update them, and we live in SSH consoles. We have the
advantage of actually knowing all the ins and outs of SQL and all the
various Pg functions.

So what's the next step? Do we keep the docs as is with minor
improvements as the backend gets upgraded from one version to the next,
or do we really step up to the plate and make Postgresql accessible to
many new users? Do we stay behind or move forward? Is where we are good
enough now?

What's next? Do we keep arguing about how it meets our needs now, or
look at moving forward to meet the needs of the next crop of new users
who think MySQL sucks, but need better documentation?

- Ericson
Keith C. Perry wrote:
Quoting Ericson Smith <er**@did-it.com>:
Bruno Wolff III wrote:
Once you know where to look for stuff it isn't that hard to find things.


Yes, but what happens where you don't know where to look for stuff?


Fair enough- the search engine definitely are problematic and the main site
probably needs to be reorganized to clearly identify the most important URLs.
This is one of the advantages of reading through the whole manual once
to get an idea of whats there.

Sure, but who has time to read through a whole manual first? No system I
ever learned had me do that.


I'm not a very versused in Oracle but I know that when I used to spec hardware
for them the company I was with pretty much wanted us to read everything we
could get our hands on.

People absolutely should "read" the manual in at least 2 passes. The 1st to get
and overview and feel for how the documentation is put together and a 2nd
(probably on some specific topics first) to get the nuts and bolts how to do
something. I personally don't feel we should like Bruno said early people NOT
reading the manual. Saying you have not had to do that before is not really a
reason. Its counter-productive in the long run.
When I need to look things up for Postgres I use a local copy of the web
based documentation.

A good idea. But If you work for different locations (home, client's
office, office), then that becomes redundant. Besides I would be
responsible for syncing the manual from PG to each location. Besides, a
local copy would not usually have a search engine built in.


I don't see how that is redundant unless you mean, you'd have to download things
to multiple sites. You're right that is not the way to go. I think most people
get these days that the provided documentation is snapshot and will change but I
for one would not want to be online while I was riding the train to NY to look
up something that I could have cached locally. The website is the master and
the freedom to "sync" (e.g. download) is your choice.
I don't like this. It will make scrolling through a group of related
functions harder. Name anchors can be used to allow links directly to
functions.

Nope. I disagree with this one. It makes finding stuff easier if you
type "nextval()" into a search engine, and it takes you directly to the
nextval page.


I'm not sure how the search function works but I don't see how these two things
are mutually exclusive. One function per page would definitely take the context
away from where and how you might use a certain functions. I would think in the
interest of orderly presentation we would want to group things while still being
able to go directly to the function in question.

(I've never have a problem searching the documents actually. I think the search
engine there is quite good since it hit multiple versions.)
Do you see these two points as applying to only the copy of the
documentatio n on the Postgres web site, or do you see this being

distributed

either with the database (as the current documentation is) or as
a separate item (like some of the clients are)?


In this case, documentation on the website should always be primary.
Almost anyone working on modern software is always connected to the
internet. A static copy of the interactive documentation can always be
distributed with the software. But do many people even refer to the
included documentation? To be honest, I dont. The documentation in psql
(eg: \h COPY) is as far as i'll go, the next step in the main site, or
google. Why rely on documentation on your hard disk that will get out of
date soon anyway?

- Ericson Smith


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

Nov 12 '05 #110

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.