473,320 Members | 2,000 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

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 11149
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
documentation 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 YourEmailAddressHere" to ma*******@postgresql.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
documentation 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*******@postgresql.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*******@postgresql.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
documentation 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*******@postgresql.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
documentation 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
documentation 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*******@postgresql.org so that your
message can get through to the mailing list cleanly

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

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?


I don't aggree that splitting up the documentation into very small pages
is a good idea. Most of the other other suggestions you made seemed good.

I also think that using a local copie of the documentation needs to be doable
(though some features may be lost when using it this way).

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

Nov 12 '05 #111
Quoting "B. van Ouwerkerk" <bv*@atz.nl>:
SNIP
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.)

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


No offence.. but..

Not clear enough? Not sure. What I do think is that some pages do not go
into greater detail where they could and imo should.

I have presented this before as an example. If you install PG you're
supposed to create a user postgres but nobody writes about what shell that
user needs and even if that user is supposed to have a shell at all..
homedir etc?? dunno..


Hmmmm. Ok, I had several gut reactions...

1) The shell doesn't matter unless you're interfacing to the DB with
shell scripts. In that case pick your poison
2) I wonder how the linux skills set of those installing PG are
3) there are several ways to add users in linux
3) Wait- forget linux what about FreeBSD the other OS'

Conclusion, we can't possibly do detailed descriptions for every nuance BUT, I
do understand what you mean.

http://www.postgresql.org/docs/curre...#INSTALL-SHORT

I suppose could be expanded (or at least commented). That section should
probably read as overview since we still what the "long" version read too.

I was going to upgrade to 7.4.1 on my laptop so if people think a "Installing
PostgreSQL on Linux" technote is needed (and does not already exsist in another
form) then I'd be more than happy to do it.
Another example? alright, data types. I found a very helpful list at the
website but I didn't see the limitations per type (maximum lenght like
MySQL says varchar max 255), or is it hidden somewhere on the PG website?.
??? That is right in the Data Types chapter...

http://www.postgresql.org/docs/7.4/static/datatype.html
While working on PG with PHP I noticed several warnings and notices. The PG
docs did mention all of them but not if they are good or bad so the hunting
continues via google.
FWIW, if you feed the message to the PG search it doesn't return anything.

It would certainly help if the docs would clarify if something is good or
bad.
I was just running something else so my mind is not mush but I thought the
messages reported were prepending with the standard syslog severity level, no?
Some messages ago I saw someone writing about something like "this is the
manual not handholding". IMO there is a difference between a well written
and complete manual and handholding.
Having said that, I realise it's a lot of work to keep good documentation
into synch with development..
What was meant there (for my part in that) is that the docs are very complete
when you consider them as references. That is really what you are going to need
after you learn the product. I think what is coming out of this discussion
today is that we the current docs are references and might scare of people who
are need to SQL and/or PG so, we need something else to get them going and used
to how things are done in the PG world.
If find the search on Postgresql.org slow and not always very logical, but
I think that has been said before..
If this was IRC and we had a word bot slow and search would be in the top 5
today :)
B.
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

--
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 4: Don't 'kill -9' the postmaster

Nov 12 '05 #112
Hello all,

am I the only one preferring plain old printed documentation? Or do you
all have 55 inch gigapixel displays being able to show browser based
documentation, an editor, a debugger and the application to be
developed at the same time?

IMHO HTML or similiar documentation with links and full text search
engines is quite useful to find just the little piece of information
that is missing - or a user´s comment to the documented matter (the
commented PHP online documentation is a good example for that), but if
you seriously develop something, some kind of printed matter is
unbeatable:

You can put it on your desk besides the display, not using precious
space on the display itself;

you can add your own comments and experiences by writing them with a
simple pencil next to the published information;

you can study this kind of documentation without switching on a
computer, nearly everywhere, as long as there is some light.

Of course sometimes fancy search engines may speed up looking for
special information, but these situations are quite rare compared with
the need for the knowledge how things work and can be used.

So if documentation is provided as "browseable" (like HTML), it should
_always_ be acomplished by "printable" equal documentation as well, and
not just HTML without formatting elements but really printable, like
Postscript or PDF, neatly formatted.

YMMV.

Regards, Frank.

On Mon, 29 Dec 2003 16:45:40 -0500 Ericson Smith <er**@did-it.com> sat
down, thought long and then wrote:
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
documentation 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.



--
Frank Finner

Memory follows memory, memory defeats memory; some things are banished
only into the realms of our rich imaginings - but this does not mean
that they do not or cannot or will not exist - they exist! They exist!
(M. Moorcock, "The Revenge Of The Rose")

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

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

Nov 12 '05 #113
I have presented this before as an example. If you install PG you're
supposed to create a user postgres but nobody writes about what shell that
user needs and even if that user is supposed to have a shell at all..
homedir etc?? dunno..
Hmmmm. Ok, I had several gut reactions...

1) The shell doesn't matter unless you're interfacing to the DB with
shell scripts. In that case pick your poison
2) I wonder how the linux skills set of those installing PG are
3) there are several ways to add users in linux
3) Wait- forget linux what about FreeBSD the other OS'


I'm not asking to explain how to add users to the system.

I assume there is something you might even call a recommended setup.. It
would be nice if that was included in the docs. I realise that at some
point most admins will adapt it to their own ideas.
Conclusion, we can't possibly do detailed descriptions for every nuance BUT, I
do understand what you mean.
A recommended setup could be included for say Linux that would allow users
of other OS's to adapt it to their own OS. Having said that, I think most
of the install is the same for all supported operating systems.
I was going to upgrade to 7.4.1 on my laptop so if people think a "Installing
PostgreSQL on Linux" technote is needed (and does not already exsist in
another
form) then I'd be more than happy to do it.


The manual is clear on this part.
Another example? alright, data types. I found a very helpful list at the
website but I didn't see the limitations per type (maximum lenght like
MySQL says varchar max 255), or is it hidden somewhere on the PG website?.


??? That is right in the Data Types chapter...

http://www.postgresql.org/docs/7.4/static/datatype.html


I still don't find it. I know you can do a varchar(255) but what is the
maximum PG will allow? Is there a maximum?
In short, how much can I put into the field before it breaks.

But perhaps I should keep my mouth shut until I have been reading a good
book ;-) still think it should be in the docs though.
It would certainly help if the docs would clarify if something is good or
bad.


I was just running something else so my mind is not mush but I thought the
messages reported were prepending with the standard syslog severity level, no?


It says either WARNING, NOTICE (IIRC),??. But the information from the docs
are not clear on if you want to find out how severe it is. And perhaps ways
to prevent them? Although that might depend much on the code.. and isn't
interesting once you know how to work with PG..
Some messages ago I saw someone writing about something like "this is the
manual not handholding". IMO there is a difference between a well written
and complete manual and handholding.
Having said that, I realise it's a lot of work to keep good documentation
into synch with development..


What was meant there (for my part in that) is that the docs are very complete
when you consider them as references. That is really what you are going
to need
after you learn the product. I think what is coming out of this discussion
today is that we the current docs are references and might scare of people who
are need to SQL and/or PG so, we need something else to get them going and
used
to how things are done in the PG world.


I know a fair bit of SQL, just wanne know more about PG. Next year I will
start shopping at the nearest bookstore to see what they have on PG..
Hopefully there is a book that compares to the book MySQL but then for PG..

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

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

Nov 12 '05 #114
On this very topic, and digressing a little, I lost track of the
XML/Jade PDF document problems thread as it moved across different
lists. Was that ever resolved, or will the 7.4 PDF docs still be
sometime off?

T.

Frank Finner wrote:
Hello all,

am I the only one preferring plain old printed documentation? Or do you
all have 55 inch gigapixel displays being able to show browser based
documentation, an editor, a debugger and the application to be
developed at the same time?

IMHO HTML or similiar documentation with links and full text search
engines is quite useful to find just the little piece of information
that is missing - or a user´s comment to the documented matter (the
commented PHP online documentation is a good example for that), but if
you seriously develop something, some kind of printed matter is
unbeatable:

You can put it on your desk besides the display, not using precious
space on the display itself;

you can add your own comments and experiences by writing them with a
simple pencil next to the published information;

you can study this kind of documentation without switching on a
computer, nearly everywhere, as long as there is some light.

Of course sometimes fancy search engines may speed up looking for
special information, but these situations are quite rare compared with
the need for the knowledge how things work and can be used.

So if documentation is provided as "browseable" (like HTML), it should
_always_ be acomplished by "printable" equal documentation as well, and
not just HTML without formatting elements but really printable, like
Postscript or PDF, neatly formatted.

YMMV.

Regards, Frank.

On Mon, 29 Dec 2003 16:45:40 -0500 Ericson Smith <er**@did-it.com> sat
down, thought long and then wrote:
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
>documentation 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.




Nov 12 '05 #115
Actually, sometimes these questions will be postgres specific, and this is
where the docs are too light.

An example is an update statement using values from a correlated subquery.
Here's example code in pgsql:

update PHOTO.WPImage
set WPImageStateID = 3,
Width = WPImageHeader.Width,
Height = WPImageHeader.Height,
ContentType = WPImageHeader.ContentType,
ContentLength = WPImageHeader.ContentLength
where WPImage.WDResourceID = WPImageHeader.WDResourceID
and WPImage.WDResourceID = pResourceID
and WPImage.WPSizeTypeID = 0;

In Oracle this might be written:

update PHOTO.WPImage i
set WPImageStateID = 3,
(Width, Height, ContentType, ContentLength) = (
select Width, Height, ContentType, ContentLength
from PHOTO.WPImageHeader ih
where ih.WDResourceID = i.WDResourceID)
where WPImage.WDResourceID = pResourceID
and WPImage.WPSizeTypeID = 0;

You'll notice that the syntax is entirely different, and very relevant for
inclusion in the docs for each database's update statement.

I've mentioned it before but here it is again, contrast this explanation
of the UPDATE command in postgres with Oracle's explanation. Which one
would explain how to make use of a correlated subquery without resorting
to more googling or the list?

postgres: http://www.postgres.org/docs/current...ql-update.html

Oracle: http://miami.int.gu.edu.au/dbs/7016/...7a.htm#2067717

My point is not so much that the docs are difficult for newbies (and they
probably are), but that they just lack sufficient meat which really ought
to be included.

John Sidney-Woollett

Bruno Wolff III said:
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*******@postgresql.org so that your
message can get through to the mailing list cleanly

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #116
El Lun 29 Dic 2003 20:24, B. van Ouwerkerk escribió:
Another example? alright, data types. I found a very helpful list at the
website but I didn't see the limitations per type (maximum lenght like
MySQL says varchar max 255), or is it hidden somewhere on the PG
website?.

I can recall that Informix had a maximun of 255 characters in the varchar,
which was documented, but if I created a table with varchar(350) it would
silently default to 255. Very nasty. :-(
??? That is right in the Data Types chapter...

http://www.postgresql.org/docs/7.4/static/datatype.html
I still don't find it. I know you can do a varchar(255) but what is the
maximum PG will allow? Is there a maximum?
In short, how much can I put into the field before it breaks.


As it says in
http://www.postgresql.org/docs/7.4/s...haracter.html:

SQL defines two primary character types: character varying(n) and
character(n), where n is a positive integer. Both of these types can store
strings up to n characters in length.

Does it say that there is a limit? Yes surely there is one, which most likely
will depends on the Processor and OS you are running (64 bit or 32 bit), but
anyway, such log varchars wouldn't be that recommended, and maybe the TEXT
data type would be more suitable.
But perhaps I should keep my mouth shut until I have been reading a good
book ;-) still think it should be in the docs though.


You should! :-)

--
select 'mmarques' || '@' || 'unl.edu.ar' AS email;
-----------------------------------------------------------------
Martín Marqués | mm******@unl.edu.ar
Programador, Administrador, DBA | Centro de Telemática
Universidad Nacional
del Litoral
-----------------------------------------------------------------
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 12 '05 #117

On Dec 29, 2003, at 6:40, Ericson Smith wrote:
In terms of using MySQL or Postgresql, lets all face it, most data
storage work could be easily and efficiently handled by text files,
since there needs to be just infrequent inserts and updates, and
mostly reads. The majority of interfaces exposed on the web follow
this paradigm, and include:
* Content management
* Catalogs
* Shopping cart stuff
* User management

Yes, our powerful and easy to use PG can do all of that too, but
SQLite, Sleepycat DBM files


In case of SQLite, BDB, plain files, etc... that all requires there to
be only a single system running your app and DB through the lifetime of
the application.

Transactions are definitely required for most of those things to work
correctly (how do you turn a shopping cart into an order correctly
without a transaction?). SQLite and BDB will get you there given the
previous caveat.

Neither really gives you an easy way to look at your data directly.
SQLite's tools are no psql, and I've had problems trying to read data
from apps that use sqlite while it's got the thing open (file locking
problems).

--
SPY My girlfriend asked me which one I like better.
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <du****@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. ____________
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 12 '05 #118

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 <du****@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. ____________
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 12 '05 #119
On Sun, 28 Dec 2003, Keith C. Perry wrote:
Admittedly this deterrent won't stop a determined newbie from finding
what they are after, but I'm sure there are some folk who would just
assume that postgres is deficient in this area. Note some previous posts
from others which demonstrates my point.
http://archives.postgresql.org/pgsql...2/msg01358.php

This gentleman finally found pgadmin III which solved his problem. But
I'm sure he had to look for it.


Short of the README file with the source release and reorganizing the web site.
I don't see what else could be done. I sincerely hope we're not going the path
of MS and trying to make things "idiot proof". PostgreSQL is robust complex
product and at a certain point I would think the powers that be would have to
say enough is enough as it relates to trying to make things easy.

On a side note though, I did try to search of "php interface" (something I know
nothing about as it relates to PG) from the search link on the main website and
I had to cancel it because it never returned anything after several minutes.
That definitely would be frustrating to a new/prospective user.


I suggest that these issues, and, other issues on the thread, go to the
points that I raised, in the thread about PostgreSQL training.

From my understanding, issues such as the PHP API, the Perl DBI, and
other interfacing, for example, are covered in the "Teach Yourself MySQL
In 21 Days" book. Similarly, also, things like pgaccess and pgadmin,
could be included in a "Teach Yourself PostgreSQL in 21 Days" book, or
equivalent, if someone would create one. And, I believe that such a
book, if done well, would have a market

This is why, as I previously said, what is needed, is a formalised,
standardised, structured, PostgreSQL training course (or set of
courses).

It is alright for people in this thread, to say "But they are MySQL, and
MySQL is not as powerful as PostgreSQL, so who cares what advantages
there are in MySQL", but MySQL appears to be more mature, as it has
things like standardised, formalised, structured, training courses and
secrtifications, and, the "Teach Yourself MySQL in 21 Days" book, and
that series of books has set exercises, etc, to aid the learning, and,
as far as I am aware, PostgreSQL has no equivalent of those things.

What PostgreSQL appears to have, is various books about it, and,
resources scattered, those books and resources, from my understanding,
are reference books and resources, rather than learning (Teach
Yourself) resources, and various institutions offering training,
in specific locations. But, it appears to have nothing like the MySQL
worldwide standardised, formalised, structured, training and
certification, and, the Teach Yourself MySQL in 21 Days" book.

Perhaps, a good development would be to develop a PostgreSQL curriculum,
with modules, starting with how to instal and configure PostgreSQL,
database design techniques, using basic SQL, using more advanced
features of SQL, API's, DBI's and ODBC and JDBC, optimising queries,
etc, showing schema, etc, and performance tuning, and so on.

Doing this on a top-down basis, could result in having published on the
web, HTML pages and printable PDF files, of modules, that would take a
person from little or no database knowledge, through to the level of
PostgreSQL guru.

There appears to have been resistance to these things, using the "build
it and they will come" attitude - "PostgreSQL is a better DBMS, so
people will flock to it", but, if it is made difficult for people to
migrate, or to learn it, are they really likely to flock to PostgreSQL?

This may appear like "flogging a dead horse", but, as I have said, I
believe that this has been covered in the PostgreSQL training thread,
and, again, I suggest that what PostgreSQL really needs, is formalised,
standardised, structured, training and certification, and, the
willingness of the PostgreSQL community to have these things, otherwise,
as I said in the aforementioned thread, the PostgreSQL people are to be
regarded as with the Perl community people - using the title JAPH - for
the Perl community, "Just Another Perl Hacker", and, for the PostgreSQL
community, "Just Another PostgreSQL Hacker". Sure, Perl is more powerful
than PHP, but Perl practitioners tend to be regarded as sorcerers, and
Perl programming, as a black art, and, PostgreSQL probably the same, in
the absence of formalised, standardised, structured, training and
certification, and, resources like the Teach Yourself MySQL in 21 Days"
book, which things would equally make learning PostgreSQL, and, gaining
formal recognition for PostgreSQL skills, through the certifications,
available to the common people, rather than making PostgreSQL
programming, a black art with a secret society atmosphere, with the
policy "If you can find it, you might be able to learn it".

It is useful, to have the resources that exist, including the support
from the mailing lists, but, what is sorely lacking, is the existence
of the things that I have repeatedly mentioned; formalised,
standardised, structured, training and certification, and, a "Teach
Yourself PostgreSQLin 21 Days" book, with appropriate set exercises, as
in any good trauining course.

When PostgreSQL has these, then it will have achieved the maturity of
MySQL, and other DBMS's, like Oracle, etc., and, then, PostgreSQL might
become widely used, and displace the other DBMS's.

Until then, it will likely be still regarded as a hacker's DBMS, as Perl
is regarded a language for hackers, or hack programmers.

--
Bret Busby
Armadale
West Australia
...............

"So once you do know what the question actually is,
you'll know what the answer means."
- Deep Thought,
Chapter 28 of
"The Hitchhiker's Guide to the Galaxy:
A Trilogy In Four Parts",
written by Douglas Adams,
published by Pan Books, 1992
.................................................. ...
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #120
"Ericson Smith" <er**@did-it.com> Wrote:
A documentation system like the one over at http://php.net, would be
fantastic for Postgresql. There could be lookups based on SQL commands,
Functions, and Sitewide Searches. This alone would go a long way to
expose PHP to "the masses".
Here is the problem, IMO. PHP has a very well developed documentation
system which already closely parallels the PostgreSQL docs-- i.e. light
tutorial, with more advanced manual sections, etc. In fact, the PostgreSQL
documentation has more depth and is more comprehensive than the PHP manual
(which is broad and shallow)..

However, a language like PHP is very different from an enterprise DB, so our
tutorial really doesn't help a newbie to databases understand how to USE
PostgreSQL. In order to do this, it would need to cover a bunch of other
topics as well, such as normalization, etc. The result would be something
that you probably would not want to include in your standard reference
manual.

In other threads, I have been vocal on the need for a community-maintained
PostgreSQL curriculum separate from the official PostgreSQL docs. I
honestly think that this need would be well addressed by such a curriculum.
The closest thing that is available at the moment, IMO, is Bruce Momjian's
book.
In terms of using MySQL or Postgresql, lets all face it, most data
storage work could be easily and efficiently handled by text files,
since there needs to be just infrequent inserts and updates, and mostly
reads. The majority of interfaces exposed on the web follow this
paradigm, and include:
* Content management
* Catalogs
* Shopping cart stuff
* User management
True, until you need transactional control. Then text files break down very
fast.
Yes, our powerful and easy to use PG can do all of that too, but SQLite,
Sleepycat DBM files and MySQL can do it as well. There are going to be
even more migrations for Oracle to MySQL than from Oracle to PG, because
so many of those Oracle installations were overkill in the first place.
Perhaps, except that Oracle DBA's may find PostgreSQL more to their liking
than MySQL.

Getting mindshare is a different problem. That requires PG to have a
full time effective press person. This press person would need to be in
touch with the press constantly to tell them things like:
* PG is a great back for windows clients using ODBC/MS Access/Excel
* PG is a "real" database comparable to Oracle
* PG costs nothing
* Free support is fabulous, and paid support is available
* Development is constant
And this need is not filled by the Advocacy group how? If we were to do as
you propose, who would pay that person?
In the end, I believe that PG needs to move into an organizational
structure so that its considerable assets can be fully realized, its
wonderful developers may be fully compensated, and commercial users (our
bread and butter), can have an official place to help sponsor features
of the system and so on. All this is more than a website. Someone posted
pictures of the PG booth at a show recently. It was nice, but there was
this one sad guy shrouded in darkness -- I felt depressed, because
that's how PG advocacy felt.


I am not opposed to the idea of a non-profit organization similar to those
that run Apache, XFree86, etc. I think it would take some work to do, and
there may need to be some debate to iron out how this would work. But I am
not sure that it is the only or even the best way.

Best Wishes,
Chris Travers
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 12 '05 #121
On Sat, 27 Dec 2003, Chris Travers wrote:
Date: Sat, 27 Dec 2003 18:44:48 +0700
From: Chris Travers <ch***@travelamericas.com>
To: Marc G. Fournier <sc*****@postgresql.org>
Cc: as*******@hotpop.com, pg***********@postgresql.org,
pg***********@postgresql.org
Subject: Re: [GENERAL] Is my MySQL Gaining ?


<snip>
In short, I do not see MySQL as any sort of threat to PostgreSQL, near or
long-term. PostgreSQL will continue when MySQL no longer exists. Firebird
is a more serious competitor long-term, though I found it to be hard to
learn when compared to PostgreSQL. It has a long way to go before being as
easy to use as PostgreSQL.


I suggest that it is a bit premature, to suggest that MySQL will
disappear, and that PostgreSQL will still exist.

Each does have its advantages, and, people develop things in parallel in
the two different systems.

For example, on the perl-gedcom list, people have developed, in
parallel, genealogy database systems that they use, some using MySQL,
some using PostgreSQL. People have their preferences, as some still use
(or require to be used) MS Access, or Foxpro, or SQL-Server, or
Informix, etc.

Does PostgreSQL yet allow the user or programmer, to determine where the
database will be stored? From memory, that has (or had) been a
shortcoming of PodtgreSQL; there was no control as to where the database
was stored, so that, for example, from my understanding, where an ISP
allowed PostgreSQL usage for web sites, all of the PostgreSQL databases
of all the ISP account holders, were stored in the same location, which
was not under the account-holder's home directory; similarly, if I, on a
LAN, create a database InventoryThing, as user frednerk, and, create a
database AccountsThing, as user joebloggs, my understanding is that both
databases will be stored in a central PostgreSQL repository, rather than
under each user home directory. Thus, if the frednerk home directory and
everything under it, is backed up by frednerk, it appears that
InventoryThing is not backed up, and, similarly, with joebloggs and
AccountsThing. Likewise with separate ISP accounts and any PostgreSQL
databases that they have and use on their web sites. Clarification of
whether my understanding is correct, would be appreciated.

--
Bret Busby
Armadale
West Australia
...............

"So once you do know what the question actually is,
you'll know what the answer means."
- Deep Thought,
Chapter 28 of
"The Hitchhiker's Guide to the Galaxy:
A Trilogy In Four Parts",
written by Douglas Adams,
published by Pan Books, 1992
.................................................. ...
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #122
Bret Busby <br**@busby.net> writes:
Does PostgreSQL yet allow the user or programmer, to determine where the
database will be stored?


You speak as though you think that would be a good idea.

In my mind, "where the database is stored" is not a matter for users,
nor for programmers, but for DBAs --- that is, the grunts who have to
worry about backup policies and suchlike. This is not an issue that
should be exposed at the SQL-command level, and therefore it does not
concern either users or database programmers.

That's not to say that we don't have work to do here. There's
considerable interest in developing "tablespace" features to help the
DBA manage his problems. But I absolutely will not buy into any
suggestion that user foo's tables must be stored in user foo's home
directory (even if I thought that Postgres user foo must correspond
to a local Unix user foo ... which I don't ...)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #123
Does it say that there is a limit? Yes surely there is one, which most likely
will depends on the Processor and OS you are running (64 bit or 32 bit), but
anyway, such log varchars wouldn't be that recommended, and maybe the TEXT
data type would be more suitable.


If you are used to MySQL you're used to a maximum limit because of MySQL
will set a limit.
This kind of information is interesting if you're trying to understand
PostgreSQL.

FWIW, we already started to use text :-)

B.
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 12 '05 #124
However, a language like PHP is very different from an enterprise DB, so our
tutorial really doesn't help a newbie to databases understand how to USE
PostgreSQL. In order to do this, it would need to cover a bunch of other
topics as well, such as normalization, etc. The result would be something
that you probably would not want to include in your standard reference
manual.


IMO normalization is something not specific for PostgreSQL. Although some
individuals on this list seem to think otherwise, normalization is just as
important when you're using MySQL.

And even if you want to include that kind of information you could do this
by linking to good information already online. There are several
informative articles at both phpbuilder and devshed.
But this would only be relevant if you're completely new to designing
databases.

B.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #125
On Tue, 30 Dec 2003, Tom Lane wrote:
Date: Tue, 30 Dec 2003 02:07:23 -0500
From: Tom Lane <tg*@sss.pgh.pa.us>
To: Bret Busby <br**@busby.net>
Cc: pg***********@postgresql.org, pg***********@postgresql.org
Subject: Re: [GENERAL] Is my MySQL Gaining ?

Bret Busby <br**@busby.net> writes:
Does PostgreSQL yet allow the user or programmer, to determine where the
database will be stored?


You speak as though you think that would be a good idea.

In my mind, "where the database is stored" is not a matter for users,
nor for programmers, but for DBAs --- that is, the grunts who have to
worry about backup policies and suchlike. This is not an issue that
should be exposed at the SQL-command level, and therefore it does not
concern either users or database programmers.

That's not to say that we don't have work to do here. There's
considerable interest in developing "tablespace" features to help the
DBA manage his problems. But I absolutely will not buy into any
suggestion that user foo's tables must be stored in user foo's home
directory (even if I thought that Postgres user foo must correspond
to a local Unix user foo ... which I don't ...)

regards, tom lane


This is where terminology becomes amusing.

I meant the OS user, not the DBMS user, and I am not suggesting that
DBMS users should be able to set where their tables are stored.

All kinds of scenarios can arise; where the DBA and the developer are
the same person, or, employed in the same department of the same
company; where the DBA is employed by the company, and the developer is
a contractor, or an employee of a contractor, and, as I previosuly
mentioned, the scenario where an ISP, by hosting a web site with a
database backend, has a database in the same holding area as is held all
the databases of all of the ISP's clients who similarly have web sites
with database backends.

I would feel more confident about having a personal database "on the
Internet"; a backend to my web site, if I knew that the database wasn't
thrown into the same storage area as everyone of the ISP's other account
holders, who also have the same DBMS database backends to their web
sites. You never know what else is sharing the same storage area, or how
safe your database is in there. It is a bit like having a cat; I would
rather that the cat is with me, and that I know where it is, and what is
happening with the cat, than having the cat locked away in a common room
for all cats. Also, using that analogy, if I decide to move away with my
cat, if it is with me, it is much simpler, and, cleaner, for me to
simply pick up the cat and take it with me, than to try to find all of
its bits, in a common room full of other cats. If I have a database
system hosted by an ISP, and I try to move it to another ISP, surely, it
would be simpler and cleaner, if I know that the database is stored in
or under my home directory with the ISP, than having the database stored
in a central repository with all of the other accounts holders'
databases.

There is also the issue of security, in the same context; I would feel
much more secure, with a database hosted by an ISP, if I could control
the privileges on the database directory, rather than allowing the ISP
the control. Having been a user on various UNIX systems, I have seen
some pretty lax security by systems administrators, and other users, and
I am reminded of a senior university computing lecturer, who had the
exam for an advanced computing unit, with such lax security that some
students wandering through the system, found the exam, and, when they
sat the exam, were surprisingly well prepared (no, I was not one of the
students), resulting in all the students in the unit, having to re-sit
the exam, and, other effects. A DBA should be able to control where a
database is stored, and the level of security applicable to where the
database is stored (privileges applicable to the directory, etc), and,
as I have previously mentioned, it can occur that the DBA and the
developer/programmer, are the same person.

As an example, on a personal basis, if I ever get the number of names in
my genealogy system, up to around 10,000, I would really want, if using
a database backend (which would, I believe, be required), to have
control over where the data is stored, so that I can easily and reliably
back it up, as such data can be unreplaceable, and can take decades to
accumulate.

Similarly, for commercial databases, now that DVD's are writable,
backing up a largish database, using OS backing up, would be much
better, and moreso, witth the data for a database, stored where it is
wanted.

I am not sure whether it can all be done with symbolic links, to place
PostgreSQL databases where a (OS, not DBMS) user or developer or DBA
wants them to be stored, but I suggest that provision should exist for a
person to determine where the person's (as owner of the database)
database file(s) exist, for security, backing up, etc.

--
Bret Busby
Armadale
West Australia
...............

"So once you do know what the question actually is,
you'll know what the answer means."
- Deep Thought,
Chapter 28 of
"The Hitchhiker's Guide to the Galaxy:
A Trilogy In Four Parts",
written by Douglas Adams,
published by Pan Books, 1992
.................................................. ...
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 12 '05 #126

Just to poke fun at MySQl:

On Tue, 30 Dec 2003, Bret Busby wrote:
...
It is alright for people in this thread, to say "But they are MySQL, and
MySQL is not as powerful as PostgreSQL, so who cares what advantages
there are in MySQL", but MySQL appears to be more mature, as it has
things like standardised, formalised, structured, training courses and
secrtifications, and, the "Teach Yourself MySQL in 21 Days" book, and
that series of books has set exercises, etc, to aid the learning,
...


I thought MySQL was supposed to be easy to install, admin and use, how come it
takes 21 days to learn it and needs formalised training courses?
--
Nigel

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 12 '05 #127
secrtifications, and, the "Teach Yourself MySQL in 21 Days" book, and
that series of books has set exercises, etc, to aid the learning,
...


I thought MySQL was supposed to be easy to install, admin and use, how come it
takes 21 days to learn it and needs formalised training courses?


Perhaps you didn't understand it correctly?

Perhaps because not everyone is intelligent enough to learn MySQL in less
then 21 days?

I don't know that particular book myself but the book MySQL written by Paul
DuBois took me much less then 21 days :-) I have yet to find a simular book
about PostgreSQL..

IMO there's no valid reason for MySQL bashing. I'm not going to defend
either one because that kind of discussion leads to nowhere.

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

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

Nov 12 '05 #128
a contractor, or an employee of a contractor, and, as I previosuly
mentioned, the scenario where an ISP, by hosting a web site with a
database backend, has a database in the same holding area as is held all
the databases of all of the ISP's clients who similarly have web sites
with database backends.
I have yet to see security issues from storing at the same place.
There is also the issue of security, in the same context; I would feel
much more secure, with a database hosted by an ISP, if I could control
the privileges on the database directory, rather than allowing the ISP
the control.
An ISP can grant you that priv:
http://www.postgresql.org/docs/curre...sql-grant.html
Almost the same trick works with MySQL.
As an example, on a personal basis, if I ever get the number of names in
my genealogy system, up to around 10,000, I would really want, if using
a database backend (which would, I believe, be required), to have
control over where the data is stored, so that I can easily and reliably
back it up, as such data can be unreplaceable, and can take decades to
accumulate.
If you're running MySQL look at something like mysqldump. When running
PostgreSQL the information is here:
http://www.postgresql.org/docs/7.4/static/backup.html
Similarly, for commercial databases, now that DVD's are writable,
backing up a largish database, using OS backing up, would be much
better, and moreso, witth the data for a database, stored where it is
wanted.
Most running databases wouldn't like it if the backup is created with
something like tar. IMO the best way is to use the tools provided with the
product. You can create a dump with whatever tool provided and write that
dump to CD-RW/DVD/whatever.
I am not sure whether it can all be done with symbolic links, to place
PostgreSQL databases where a (OS, not DBMS) user or developer or DBA
wants them to be stored, but I suggest that provision should exist for a
person to determine where the person's (as owner of the database)
database file(s) exist, for security, backing up, etc.


And then you hit the hard limit set by quota :-)
Even if you think you can do it yourself you will have to persuade your
ISP/admin/whatever to create a symbolic link (even if that would be
possible and what you want).

B.
---------------------------(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

Nov 12 '05 #129
B. van Ouwerkerk wrote:
IMO there's no valid reason for MySQL bashing. I'm not going to defend
either one because that kind of discussion leads to nowhere.


How about pure entertainment? Or maybe because we don't have anything
better to do on a Friday night because the one girl this year who
actually said she would go out with us has stood us up? But were not
bitter at all at that slut and she uses MySQL I just no it, I bet she's
using it right now and laughing... LAUGHING at me...

See it can be very therapeutic :)

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

Nov 12 '05 #130
El Mar 30 Dic 2003 04:07, B. van Ouwerkerk escribió:
Does it say that there is a limit? Yes surely there is one, which most
likely will depends on the Processor and OS you are running (64 bit or 32
bit), but anyway, such log varchars wouldn't be that recommended, and
maybe the TEXT data type would be more suitable.


If you are used to MySQL you're used to a maximum limit because of MySQL
will set a limit.
This kind of information is interesting if you're trying to understand
PostgreSQL.


Well, maybe it's because I read some mails from Tom Lane discussing how
optimal varchar(300000) would be. :-)

--
09:25:01 up 34 days, 15:41, 2 users, load average: 0.05, 0.30, 0.38
-----------------------------------------------------------------
Martín Marqués | select 'mmarques' || '@' || 'unl.edu.ar'
Centro de Telematica | DBA, Programador, Administrador
Universidad Nacional
del Litoral
-----------------------------------------------------------------
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 12 '05 #131

If you have no control over the running postmasters, then where the
files are stored gives you no advantage at all either
for backup or security. Backing up physical files while the postmaster
running is asking for it; this is explained every three days
or so on the lists. (that should be part of some consent form for using
PG...'I acknowledge that copying physical files while
the postmaster is running is ineffective, will get me in trouble, and
promote both moral degradation and tooth decay. Please don't ask.').

As for security...the data cluster is created with 700 permissions,
owned by the postgres super-user, and the postmaster will not
even start up if the directory permissions are set otherwise.

Personally, I wouldn't trust a sysad/dba at an ISP who gave me
sufficient rights to create, say, Oracle tablespaces willy-nilly. That
would fit your
example of lazy and lax administration. (Apologies for using the 'O'
word...)

We're back into the mindset of an RDBMS being thought of as some sort
of FoxPro-on-steroids thing. That is not what Postgres, Oracle,
Sybase, etc. are.

On Dec 30, 2003, at 5:40 AM, Bret Busby wrote:
On Tue, 30 Dec 2003, Tom Lane wrote:
Date: Tue, 30 Dec 2003 02:07:23 -0500
From: Tom Lane <tg*@sss.pgh.pa.us>
To: Bret Busby <br**@busby.net>
Cc: pg***********@postgresql.org, pg***********@postgresql.org
Subject: Re: [GENERAL] Is my MySQL Gaining ?

Bret Busby <br**@busby.net> writes:
Does PostgreSQL yet allow the user or programmer, to determine where
the
database will be stored?


You speak as though you think that would be a good idea.

In my mind, "where the database is stored" is not a matter for users,
nor for programmers, but for DBAs --- that is, the grunts who have to
worry about backup policies and suchlike. This is not an issue that
should be exposed at the SQL-command level, and therefore it does not
concern either users or database programmers.

That's not to say that we don't have work to do here. There's
considerable interest in developing "tablespace" features to help the
DBA manage his problems. But I absolutely will not buy into any
suggestion that user foo's tables must be stored in user foo's home
directory (even if I thought that Postgres user foo must correspond
to a local Unix user foo ... which I don't ...)

regards, tom lane


This is where terminology becomes amusing.

I meant the OS user, not the DBMS user, and I am not suggesting that
DBMS users should be able to set where their tables are stored.

All kinds of scenarios can arise; where the DBA and the developer are
the same person, or, employed in the same department of the same
company; where the DBA is employed by the company, and the developer is
a contractor, or an employee of a contractor, and, as I previosuly
mentioned, the scenario where an ISP, by hosting a web site with a
database backend, has a database in the same holding area as is held
all
the databases of all of the ISP's clients who similarly have web sites
with database backends.

I would feel more confident about having a personal database "on the
Internet"; a backend to my web site, if I knew that the database wasn't
thrown into the same storage area as everyone of the ISP's other
account
holders, who also have the same DBMS database backends to their web
sites. You never know what else is sharing the same storage area, or
how
safe your database is in there. It is a bit like having a cat; I would
rather that the cat is with me, and that I know where it is, and what
is
happening with the cat, than having the cat locked away in a common
room
for all cats. Also, using that analogy, if I decide to move away with
my
cat, if it is with me, it is much simpler, and, cleaner, for me to
simply pick up the cat and take it with me, than to try to find all of
its bits, in a common room full of other cats. If I have a database
system hosted by an ISP, and I try to move it to another ISP, surely,
it
would be simpler and cleaner, if I know that the database is stored in
or under my home directory with the ISP, than having the database
stored
in a central repository with all of the other accounts holders'
databases.

There is also the issue of security, in the same context; I would feel
much more secure, with a database hosted by an ISP, if I could control
the privileges on the database directory, rather than allowing the ISP
the control. Having been a user on various UNIX systems, I have seen
some pretty lax security by systems administrators, and other users,
and
I am reminded of a senior university computing lecturer, who had the
exam for an advanced computing unit, with such lax security that some
students wandering through the system, found the exam, and, when they
sat the exam, were surprisingly well prepared (no, I was not one of the
students), resulting in all the students in the unit, having to re-sit
the exam, and, other effects. A DBA should be able to control where a
database is stored, and the level of security applicable to where the
database is stored (privileges applicable to the directory, etc), and,
as I have previously mentioned, it can occur that the DBA and the
developer/programmer, are the same person.

As an example, on a personal basis, if I ever get the number of names
in
my genealogy system, up to around 10,000, I would really want, if using
a database backend (which would, I believe, be required), to have
control over where the data is stored, so that I can easily and
reliably
back it up, as such data can be unreplaceable, and can take decades to
accumulate.

Similarly, for commercial databases, now that DVD's are writable,
backing up a largish database, using OS backing up, would be much
better, and moreso, witth the data for a database, stored where it is
wanted.

I am not sure whether it can all be done with symbolic links, to place
PostgreSQL databases where a (OS, not DBMS) user or developer or DBA
wants them to be stored, but I suggest that provision should exist for
a
person to determine where the person's (as owner of the database)
database file(s) exist, for security, backing up, etc.

--
Bret Busby
Armadale
West Australia
..............

"So once you do know what the question actually is,
you'll know what the answer means."
- Deep Thought,
Chapter 28 of
"The Hitchhiker's Guide to the Galaxy:
A Trilogy In Four Parts",
written by Douglas Adams,
published by Pan Books, 1992
.................................................. ..
---------------------------(end of
broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to
ma*******@postgresql.org

--------------------

Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114
www.ravensfield.com
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 12 '05 #132
Personally I think that the docs are great (especially so with 7.4). Of
course they are aimed at experienced admins, so it is easier to find things
if you have a basic understanding of the RDBMS to start with. Of course
things can always be improved, but I am opposed to adding cruft to the core
documentation. Let's keep these things friendly towards experienced users
so that we can WORK efficiently.

However, Ericson does have a point, that the docs are NOT adequate if you
are new to PostgreSQL and have only used MySQL or MS Access. There have
been many ideas on how to resolve this issue, but I say that it should be
resolved outside the core docs. The example of Python has been used, with
an in-depth tutorial separate from the main docs. That way, an experienced
user can discard the tutorial.

I have argued elsewhere that a separate curriculum should be maintained, but
I also understand that that will not happen overnight. My suggestion at the
moment is to break the tutorial off so that it is not part of the main docs
(I am not satisfied that it is large enough to really fill its purpose) and
maintain it separately. I would then look at how to improve the tutorial.

Hint out there to Ericson and others. The Reference Manual section of SQL
commands is the part of the manual I use most. Procedural language sections
also are used much around here :-)

Best Wishes,
Chris Travers
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 12 '05 #133
From: "B. van Ouwerkerk" <bv*@atz.nl>:
I still don't find it. I know you can do a varchar(255) but what is the
maximum PG will allow? Is there a maximum?
In short, how much can I put into the field before it breaks.
It is not in the manual because in this case it probably doesn't matter.
Check the FAQ. I believe that the maximum in a field in around 1GB. More
text than I have to store ;-) This is more of a backend-related issue, and
perhaps the limits could be handled in the introduction of the datatypes
section.
I know a fair bit of SQL, just wanne know more about PG. Next year I will
start shopping at the nearest bookstore to see what they have on PG..
Hopefully there is a book that compares to the book MySQL but then for

PG..

Look for Bruce's book.

Best Wishes,
Chris Travers
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 12 '05 #134
At 20:00 30-12-2003 +0700, Chris Travers wrote:
Personally I think that the docs are great (especially so with 7.4). Of
course they are aimed at experienced admins, so it is easier to find things
if you have a basic understanding of the RDBMS to start with. Of course
things can always be improved, but I am opposed to adding cruft to the core
documentation. Let's keep these things friendly towards experienced users
so that we can WORK efficiently.


IMO you can have both. How much would it hurt if there was a bit more
information? Or a link to a related topic (as someone else suggested before).

If I think about using a certain PHP function I might want to double check
on the exact syntax or to look at the minimum version required. So I go to
the PHP.net website and quickly look at it.. but a newcomer might spend
quite some time on the same page..
The same could become true for the PostgreSQL docs I gues. Meaning I will
read a bit longer on the same page then you. But only until I have
assimilated the information..

All I would ask is a bit more information in the docs then found at
present, add information where it currently stops without talking to much :-)

I'm quite sure there are enough knowledgeable persons around to fill in the
gaps found at present. But perhaps the interactive version of the docs
might serve a great perpose here.
B.
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 12 '05 #135
"Bret Busby" <br**@busby.net> Wrote:
On Sat, 27 Dec 2003, Chris Travers wrote:
In short, I do not see MySQL as any sort of threat to PostgreSQL, near or long-term. PostgreSQL will continue when MySQL no longer exists. Firebird is a more serious competitor long-term, though I found it to be hard to
learn when compared to PostgreSQL. It has a long way to go before being as easy to use as PostgreSQL.
I suggest that it is a bit premature, to suggest that MySQL will
disappear, and that PostgreSQL will still exist.

Ok, fair enough, and since it is GPL'd when it is no longer maintained, it
will still exist ;-). One of the things that makes MySQL different than,
say, Nautilus is the fact that you have client libs licensed under the GPL.
Unless MySQL AB decides to change this, we will have a strong advantage, and
I don't see this changing anytime soon.

But I still think that MySQL is more likely to become non-viable than
PostgreSQL... MySQL is not helping their case much (now that PHP will not
enable MySQL by default anymore due to licensing issues).
Each does have its advantages, and, people develop things in parallel in
the two different systems.
I have developed systems that support both. I understand what you mean.

For example, on the perl-gedcom list, people have developed, in
parallel, genealogy database systems that they use, some using MySQL,
some using PostgreSQL. People have their preferences, as some still use
(or require to be used) MS Access, or Foxpro, or SQL-Server, or
Informix, etc.

Does PostgreSQL yet allow the user or programmer, to determine where the
database will be stored?


I think you mean DBA rather than user or programmer. Tablespaces are in the
works and will allow finer tuning of database storage.

Best Wishes,
Chris Travers
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 12 '05 #136
On Mon, Dec 29, 2003 at 23:41:22 -0000,
John Sidney-Woollett <jo****@wardbrook.com> wrote:
Actually, sometimes these questions will be postgres specific, and this is
where the docs are too light.

An example is an update statement using values from a correlated subquery.
Here's example code in pgsql:

update PHOTO.WPImage
set WPImageStateID = 3,
Width = WPImageHeader.Width,
Height = WPImageHeader.Height,
ContentType = WPImageHeader.ContentType,
ContentLength = WPImageHeader.ContentLength
where WPImage.WDResourceID = WPImageHeader.WDResourceID
and WPImage.WDResourceID = pResourceID
and WPImage.WPSizeTypeID = 0;

In Oracle this might be written:

update PHOTO.WPImage i
set WPImageStateID = 3,
(Width, Height, ContentType, ContentLength) = (
select Width, Height, ContentType, ContentLength
from PHOTO.WPImageHeader ih
where ih.WDResourceID = i.WDResourceID)
where WPImage.WDResourceID = pResourceID
and WPImage.WPSizeTypeID = 0;

You'll notice that the syntax is entirely different, and very relevant for
inclusion in the docs for each database's update statement.
The Postgres example uses a join instead of subselects. You could have
used subselects in postgres, but because there is currently not a way
to set more than one column at a time from one subselect, you would
have to repeat the subselect 4 times.

I am not convinced that this needs to be documented in the section on
the update statement. This is something that would belong in an oracle
to postgres conversion guide.
I've mentioned it before but here it is again, contrast this explanation
of the UPDATE command in postgres with Oracle's explanation. Which one
would explain how to make use of a correlated subquery without resorting
to more googling or the list?

postgres: http://www.postgres.org/docs/current...ql-update.html

Oracle: http://miami.int.gu.edu.au/dbs/7016/...7a.htm#2067717

My point is not so much that the docs are difficult for newbies (and they
probably are), but that they just lack sufficient meat which really ought
to be included.


I still don't see that there needs to be a lot more added to the postgres
update command documentation. The main thing missing is links to the
syntax definitions for things like from list, condition and expression.
Currently you just have to know that the syntax for from items and conditions
is described with the select documentation and that expression syntax is
covered in the value expressions chapters under sql syntax.

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

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

Nov 12 '05 #137

rw****@averillpark.net says...
Check http://firebird.sourceforge.net/
note that Firebird (the Interbase spinoff) used the name before
Firebird (the Mozilla spinoff) did.

The Mozilla people have undertaken to change this, but are dragging
their feet, much to the disgust of the real Firebirders.
Paul...
richard


--
plinehan y_a_h_o_o and d_o_t com
C++ Builder 5 SP1, Interbase 6.0.1.6 IBX 5.04 W2K Pro
Please do not top-post.

"XML avoids the fundamental question of what we should do,
by focusing entirely on how we should do it."

quote from http://www.metatorial.com
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #138


jo****@wardbrook.com says...

As long time Oracle developer recently converted to Postgres, I think that
you would all do better to use Oracle as your benchmark instead of MySQL.

<... Theme development snipped>
Very good post and point!
Paul...
--
plinehan y_a_h_o_o and d_o_t com
C++ Builder 5 SP1, Interbase 6.0.1.6 IBX 5.04 W2K Pro
Please do not top-post.

"XML avoids the fundamental question of what we should do,
by focusing entirely on how we should do it."

quote from http://www.metatorial.com
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #139
RE "The main thing missing is links to the syntax definitions for things
like from list, condition and expression. Currently you just have to know
that the syntax for from items and conditions is described with the
select documentation and that expression syntax is covered in the value
expressions chapters under sql syntax."

Actually just having the links would be a great help (provided it took you
to the relevant section of the page rather than the start).

A fast full text index of the docs, and related material online would help
enormously - I see that something is in the pipline... Hooray!

John

Bruno Wolff III said:
On Mon, Dec 29, 2003 at 23:41:22 -0000,
John Sidney-Woollett <jo****@wardbrook.com> wrote:
Actually, sometimes these questions will be postgres specific, and this is
where the docs are too light.
An example is an update statement using values from a correlated subquery.
Here's example code in pgsql:
update PHOTO.WPImage
set WPImageStateID = 3,
Width = WPImageHeader.Width,
Height = WPImageHeader.Height,
ContentType = WPImageHeader.ContentType,
ContentLength = WPImageHeader.ContentLength
where WPImage.WDResourceID = WPImageHeader.WDResourceID
and WPImage.WDResourceID = pResourceID
and WPImage.WPSizeTypeID = 0;
In Oracle this might be written:
update PHOTO.WPImage i
set WPImageStateID = 3,
(Width, Height, ContentType, ContentLength) = (
select Width, Height, ContentType, ContentLength
from PHOTO.WPImageHeader ih
where ih.WDResourceID = i.WDResourceID)
where WPImage.WDResourceID = pResourceID
and WPImage.WPSizeTypeID = 0;
You'll notice that the syntax is entirely different, and very relevant for
inclusion in the docs for each database's update statement.
The Postgres example uses a join instead of subselects. You could have

used subselects in postgres, but because there is currently not a way to
set more than one column at a time from one subselect, you would have to
repeat the subselect 4 times.
I am not convinced that this needs to be documented in the section on the update statement. This is something that would belong in an oracle
to postgres conversion guide.
I've mentioned it before but here it is again, contrast this explanation of the UPDATE command in postgres with Oracle's explanation. Which one would explain how to make use of a correlated subquery without
resorting to more googling or the list?
postgres:
http://www.postgres.org/docs/current...ql-update.html Oracle: http://miami.int.gu.edu.au/dbs/7016/...7a.htm#2067717
My point is not so much that the docs are difficult for newbies (and
they probably are), but that they just lack sufficient meat which really ought
to be included.
I still don't see that there needs to be a lot more added to the

postgres update command documentation. The main thing missing is links to the syntax definitions for things like from list, condition and expression.
Currently you just have to know that the syntax for from items and
conditions is described with the select documentation and that expression syntax is covered in the value expressions chapters under sql syntax.



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

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

Nov 12 '05 #140
Bruno Wolff III <br***@wolff.to> writes:
I still don't see that there needs to be a lot more added to the postgres
update command documentation. The main thing missing is links to the
syntax definitions for things like from list, condition and expression.


This is in part because before 7.4, those things were in separate
"books" and so you couldn't easily make a cross-reference to them.
Now that we build the docs as one big book, cross-references are easy.
It's just a matter of someone taking the time to go through and add
them. Do I hear a volunteer?

BTW, I'd not be in favor of separating out the Tutorial into a separate
document again, precisely because we would lose the ability for it to
easily cross-reference the main docs.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 12 '05 #141
On Tue, Dec 30, 2003 at 12:20:03 -0500,
Tom Lane <tg*@sss.pgh.pa.us> wrote:
Bruno Wolff III <br***@wolff.to> writes:
I still don't see that there needs to be a lot more added to the postgres
update command documentation. The main thing missing is links to the
syntax definitions for things like from list, condition and expression.


This is in part because before 7.4, those things were in separate
"books" and so you couldn't easily make a cross-reference to them.
Now that we build the docs as one big book, cross-references are easy.
It's just a matter of someone taking the time to go through and add
them. Do I hear a volunteer?


I will do this for the UPDATE command to get some feedback and assuming
that goes well, I am willing to go through the commands section of the
manual looking for other appropiate cross references.

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 12 '05 #142
Hello

I had queried about the issue before and tried to
google for solution. But still I am not able to find
windows version of libpq.

I installed postgresql ( not from source though )
using cygwin. It installed the header files needed for
pg development. It even installed libpq.a but not
libpq.lib ( is libpq.a windows compliant ). Where can
I get precompiled copy of latest libpq.lib.

Also this may be off list....I downloaded the source
of pgAdmin III ( to know live examples of working PG C
API ). The project needs some libs called ssleay.lib
etc. Are these pg specific or for what? Cant seem to
compile it.

I am using WinXP Pro with VC++ 6.0.

Regards
Karam

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #143
Quoting DeJuan Jackson <dj******@speedfc.com>:
B. van Ouwerkerk wrote:
IMO there's no valid reason for MySQL bashing. I'm not going to defend
either one because that kind of discussion leads to nowhere.


How about pure entertainment? Or maybe because we don't have anything
better to do on a Friday night because the one girl this year who
actually said she would go out with us has stood us up? But were not
bitter at all at that slut and she uses MySQL I just no it, I bet she's
using it right now and laughing... LAUGHING at me...

See it can be very therapeutic :)

LOL- yea, that was actually!
Seriously though- another sub-text of this thread **is** defending how MySQL
documentation is "better" than PostgreSQL's. Of course many have responded with
various opinions as to why it is not "better".

I personally don't see much weight in the arguement because comparisons by
nature are subjective. There's everyone from the person whose has just heard
what SQL stands for to the person that can receit the specifications. Couple
that with the fact that MySQL just isn't on the same level yet to be making the
comparison and what you have is a bit of a mess.

I'm not sure how this "mess" gets cleaned up but like Tom indicated earlier in
this thread, this is open source so if you want something done that is not so
high up on the list, you're probably going to have to do it yourself or at least
in a smaller group.

It seems for the MySQL folks (which I was for a very short time) I would say
that a study of SQL itself might be warranted. It just really is not
appropriate to duplicate the basics for which there is a tremendous amount of
information online already You should not have a problem finding something that
you like.

I learned PG by studying SQL and finding some examples/tutorials online and at
first trying them in mSQL, MySQL (which was difficult because it wasn't very
standard) and later in PostgreSQL. Once I understood SQL and actually played
around with some products I found having a reference (like PG's docs) to be my
bible. Those of you who are new to the product don't realize have far the docs
have come from the 6.x days nor does it really matter to you when you need a
question answered at 2am. Thats the rub!. If you have grown with one culture,
you really can't come to another one and expect to be at the same point. In a
sense you have to start over but with your mind open to a new way of doing things.

This is very similar to how people dissatified with M$ come over to Linux or the
Mac world. They are very anxious to do away with the old and get on with the
new. The problem is that they forget there is a learning curve- easier or hard.
Lets face it, a lot of people don't like to "learn" so if something new is not
"easy" to do in the long run it won't go far. Just look how new products are
marketed on TV. Not to say that that is the right way to do things- just to say
that it is done. This is always going to be a the balancing act for good
products- marketability vs. functionality

I apologize now if this seems like a dig at MySQL users- it truely is not but I
do get the sense that the issue with PG is really more an issue with
understanding SQL and RDBMS' in general.
--
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 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 12 '05 #144
On Tue, 2003-12-30 at 17:20, Tom Lane wrote:
Now that we build the docs as one big book, cross-references are easy.
It's just a matter of someone taking the time to go through and add
them. Do I hear a volunteer?


I'll have a go at it. Gradually...

--
Oliver Elphick Ol************@lfix.co.uk
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Give to him that asketh thee, and from him that would
borrow of thee turn not away."
Matthew 5:42
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #145
I want to use one subject line to discuss many different
topics on this mailing list. Which subject should I use?
Is there a prize for longest thread on this list?

- MySQL has Java support in alpha
- MySQL has documentation that newbies like
- MySQL features are alpha and 2 years away
- PostgreSQL already has MySQLs proposed features
- PostgreSQL stored procedures rock
- Can we have nested transactions, please?
- We like everything about MySQL (docs, website, 3rd party tools)
except the database
- PostgreSQL is more robust and mature
- MySQL developers are doing a 180 turn from their "you don't need
that" stance
- PostgreSQL needs volunteers for documentation enhancements
- Somebody on the list missed a date with a MySQL girlfriend
- Elephants never forget and can step on dolphins
- ...

Oh nevermind, I'll just use 'Is my MySQL Gaining?' for a subject.
Yeah, that works.

----------
Dante

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 12 '05 #146
On Wednesday 31 December 2003 05:23, Oliver Elphick wrote:
On Tue, 2003-12-30 at 17:20, Tom Lane wrote:
Now that we build the docs as one big book, cross-references are easy.
It's just a matter of someone taking the time to go through and add
them. Do I hear a volunteer?


I'll have a go at it. Gradually...


I'm with Oliver - I'll be happy to put my name down for doing a few sections
in the docs.. just name them

rgds,

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

Nov 12 '05 #147
D. Dante Lorenso wrote:
I want to use one subject line to discuss many different
topics on this mailing list. Which subject should I use?
Is there a prize for longest thread on this list?

- MySQL has Java support in alpha
- MySQL has documentation that newbies like
- MySQL features are alpha and 2 years away
- PostgreSQL already has MySQLs proposed features
- PostgreSQL stored procedures rock
- Can we have nested transactions, please?
- We like everything about MySQL (docs, website, 3rd party tools)
except the database
- PostgreSQL is more robust and mature
- MySQL developers are doing a 180 turn from their "you don't need
that" stance
- PostgreSQL needs volunteers for documentation enhancements
- Somebody on the list missed a date with a MySQL girlfriend
- Elephants never forget and can step on dolphins
- ...

Oh nevermind, I'll just use 'Is my MySQL Gaining?' for a subject.
Yeah, that works.


I think that sums the thread up nicely. :-)

--
Bruce Momjian | http://candle.pha.pa.us
pg***@candle.pha.pa.us | (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

Nov 12 '05 #148
On Fri, Dec 26, 2003 at 10:02:25AM -0500, Jan Wieck wrote:
It seems to concern MySQL now at least. They have changed their minds on
many enterprise features that PostgreSQL has for years. The strategy of
misguiding people like "you don't need foreign keys", "you don't need
stored procedures", "yadda yadda triggers", "blah blah views" didn't
work forever. So they have to add or propose those features one by one.


Anyone have a copy of their older docs where they argued that row level
locking was bad and that you should only do table level locking? :)
--
Jim C. Nasby, Database Consultant ji*@nasby.net
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

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

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

Nov 12 '05 #149
On Tuesday 30 December 2003 06:50, B. van Ouwerkerk wrote:
I don't know that particular book myself but the book MySQL written by Paul
DuBois took me much less then 21 days :-) I have yet to find a simular book
about PostgreSQL..


uh... I would have to think that Korry Douglas's book titled "PostgreSQL" from
the same publisher must be somewhat similar.

http://www.amazon.com/exec/obidos/AS...846574-6863256

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

Nov 12 '05 #150

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.