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

Home Posts Topics Members FAQ

Is my MySQL Gaining ?

Dear all,

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

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

Does this concern anyone.

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

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

Regards,
Vishal Kashyap.

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

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

Nov 12 '05
175 11574
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>>funct ions harder. Name anchors can be used to allow links
directly to>>functions.




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

the >nextval page.


Maybe if you are using google where you won't get placed at the
relevant part of the page you get pointed to. With a custom search
engine, you could reference directly to the function's entry within a
page.


Do you see these two points as applying to only the copy of the
documentatio n on the Postgres web site, or do you see this being
distribute d
either with the database (as the current documentation is) or as
a separate item (like some of the clients are)?



In this case, documentation on the website should always be primary.
Almost anyone working on modern software is always connected to the
internet. A static copy of the interactive documentation can always

be >distributed with the software. But do many people even refer to
the >included documentation? To be honest, I dont. The documentation
in psql >(eg: \h COPY) is as far as i'll go, the next step in the
main site, or >google. Why rely on documentation on your hard disk
that will get out of >date soon anyway?


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



--
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
documentatio n, 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
responsib le 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>>fun ctions 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
>documentat ion on the Postgres web site, or do you see this being
>distribute d
>either with the database (as the current documentation is) or as
>a separate item (like some of the clients are)?
>
>
>
>
>
>
>
In this case, documentation on the website should always be primary.
Almost anyone working on modern software is always connected to the
internet. A static copy of the interactive documentation can always
be >distributed with the software. But do many people even refer to
the >included documentation? To be honest, I dont. The documentation
in psql >(eg: \h COPY) is as far as i'll go, the next step in the
main site, or >google. Why rely on documentation on your hard disk
that will get out of >date soon anyway?


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




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.W idth,
Height = WPImageHeader.H eight,
ContentType = WPImageHeader.C ontentType,
ContentLength = WPImageHeader.C ontentLength
where WPImage.WDResou rceID = WPImageHeader.W DResourceID
and WPImage.WDResou rceID = pResourceID
and WPImage.WPSizeT ypeID = 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.WPImageHe ader ih
where ih.WDResourceID = i.WDResourceID)
where WPImage.WDResou rceID = pResourceID
and WPImage.WPSizeT ypeID = 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*******@postg resql.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.ed u.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

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.