Re: Usability, MySQL, Postgresql.org, gborg, contrib,

A sort of debate started by Bruce about what MySQL does better vs what
PostgreSQL could do, then there was a thread about removing "/contrib"
from the main download, and a few other posts.

I don't think these are unrelated. They all fall under the umbarella of
"How does a new user come to use PostgreSQL?"

I have come to believe it is a number of issues, it isn't just the site,
it isn't just the setup, it isn't whether or not contributed modules are
easy to find, I think it is all of these.

(1) I think the PostgreSQL web presence has been lacking for some time. I
am not a web developer myself, but I do know that the PostgreSQL site does
not seem to look and feel like other sites. The new site is better than
before, but I think it still needs some more standardization with the rest
of the web.

There are a lot of "usability" issues that can be fixed easily. Links to
the left, fluff items to the right, main message in the middle, symplified
menus, etc. Again, while I'm not a web designer, I have a small moch-up of
something I think would have more visual "clues" to new users at
http://www.mohawksoft.com/PostgreSQL.html

(2) Removing the "contrib" directory in the main download. I think this is
a good idea, but it means that we need to make it easier to make
extensions. I write a lot of extensions and I have a standard Makefile for
building them. (Granted I have to change it periodically for different
versions) You have to specify the PostgreSQL build directory to build an
extension. It isn't clear to me if there is a way to build an extension to
PostgreSQL without having built PostgreSQL first. It would be nice if
there were a standardized set of extension headers and a well documented
process to make an extension. Then we could focus on a standard API. :-)

(3) Configuration. What can I say, power users edit postgresql.conf, start
scripts, pg_hba.conf, etc. I think it can safely be said, that we need to
show non-power users the light. For this, there needs to be an
application, in some portable scripting language, that can configure
PostgreSQL. Maybe it is in the form of a web server like Samba's SWAT
utility, I don't know (A SWAT type utility could run as the PostgreSQL
user for the correct rights), but users need this. I don't think the
typical debate of "GUI tool aren't really easier" or "That's just bloat"
or "Do we even want these users using PostgreSQL" are relevent. If we want
to increase usership, this is a requirement.

(4) Blessed projects, lets play favorites. Lets find good and meaningful
extensions on gborg and ./contrib and work with the authors and make them
part of the PostgreSQL "environment." Projects like, replication, .NET
service provider, ODBC, pgAdmin, etc. are important and users need to find
them close to PostgreSQL's main location.

(5) Programming languages. We need to make a programming language standard
in PostgreSQL. plpgsql is good, but isn't someone working on a Java
language. That would be pretty slick.

(6) In keeping with item #4, lets make some Binary distributions and make
those available on the mirrors. Think about how a Windows user tries
software: Click on a site, install, and run. I could update my Windows
installer and console system and create a zipped install. I know there are
rpms and debs out there, but if you look at programs like mozilla and
realplayer, they have a pretty good installer. Maybe we could use the
Mozilla installer? What happend to the Great Bridge installer?

When all is said and done, I think the PostgreSQL project lacks a "Product
Management" group which steers the public perception and defines
usability. This is something *all* other systems have, including MySQL.

If we want to make PostgreSQL a wildly popular product, there will be some
pain. There should be a "Product Management" group. The leader(s) of this
group should be chosen carefully, as he (they) must be free to define what
PostgreSQL is. They must have a good feel for product development and
understanding of the underlying technology, but not be so techie that we
don't address the issues intended. They must be able to rally the troops
and direct development efforts. Lastly, he (they) must have the confidence
of the core hackers, as it is likely that there will be disagreements with
the direction of PostgreSQL, and it wouldn't work if "Product Management"
couldn't actually manage what the product was because nobody listened.

Is anyone really ready for this sort of commitment?

In an attempt to throw the authorities off his trail, pgsql(at)mohawksoft(dot)com transmitted:
> Is anyone really ready for this sort of commitment?

By that, I presume you mean...

"Are people prepared to stop working on the doubtless useful things
that they are working on in favor of spending their time instead on
this set of marketing-oriented systems integration tasks?"

I think the answer to that is likely a pretty clear NO.

PostgreSQL runs on numerous systems, and in order to do what you are
proposing, it would be necessary to play system favorites.

-> Configuration systems are inherently platform-specific.

-> PL/Java is well and interesting, but requires a barrel of non-free
software, which makes installation and configuration anything but
"slick."

There is _not_ going to be a "Product Management" group any time soon
that will turn around PostgreSQL into being a marketing-driven
project.

I suggest that you instead find projects that are worth doing in their
own right without having to make some mandate for a Grand Political
Restructuring. Doing individual things that are worthwhile is,
obviously, worthwhile. If some point some people in directions that,
after some number of such projects, resemble some Grand Political
Restructuring, then you'll have succeeded at the latter.

Much as you can't push on a rope (unless it's wet and frozen :-)), and
can't herd cats (although EDS did a SuperBowl commercial claiming they
could), you can't push for a Grand Political Restructuring. The best
you can do is lure people in your directions, one cat at a time...
--
(format nil "~S(at)~S" "cbbrowne" "cbbrowne.com")
http://cbbrowne.com/info/spreadsheets.html
"The theoreticians have proven that this is unsolvable, but there's
three of us, and we're smart..." -- Arthur Norman

> -> PL/Java is well and interesting, but requires a barrel of non-free
> software, which makes installation and configuration anything but
> "slick."
>
I think it's a bit unfair to say that Pl/Java requires a "barrel of non-free
software".

Pl/Java doesn't require any software besides the Java Runtime Environment
and those who have an interest in Java is *very* likely to have a JRE
installed already.

I'm currently working on getting Pl/Java running with GNU's GCJ. Aside from
a bug in gcj (reported to be fixed by the gcj people), it runs fine with
GCJ. At present it requires the HEAD version and the GCJ 3.4 branch from GNU
(not released yet). Releases of both are imminent.

If PostgreSQL was equipped with an "installer" that modules like Pl/Java
could hook into, I'd be more than willing to adhere to whatever requirements
such an installer would impose. With the present lack of such semantics, I
dare say that the installation is pretty "slick" anyway. Read this and
comment http://gborg.postgresql.org/project/pljava/genpage.php?readme.

Kind Regards,

Thomas Hallgren

"Christopher Browne" <cbbrowne(at)acm(dot)org> wrote in message
news:m3ekqbaec5(dot)fsf(at)wolfe(dot)cbbrowne(dot)com(dot)(dot)(dot)
> In an attempt to throw the authorities off his trail, pgsql(at)mohawksoft(dot)com
transmitted:
> > Is anyone really ready for this sort of commitment?
>
> By that, I presume you mean...
>
> "Are people prepared to stop working on the doubtless useful things
> that they are working on in favor of spending their time instead on
> this set of marketing-oriented systems integration tasks?"
>
> I think the answer to that is likely a pretty clear NO.
>
Perhaps more people should be attracted to the project? People that are not
just purely technical? I concur with the original posting. Not because of
the marketing aspects, but because I think PostgreSQL could benefit greatly
if it was more modularized and had a stronger long-term planning. It would
ease up a great deal for people like myself who really want to contribute.
No "grand restructuring" is needed but more thoughts need to go into
modularization and how various things plugs in to PostgreSQL, not just from
a technical "how to write the code" perspective, but also from an assembly,
deploy, and maintain angle.

PostgreSQL has a vast amount of users and the customer base is growing.
There is a demand that should not be neglected just because it's "Market
Driven". That's not fair the developers that does an excellent job with the
product. They really deserve all goodwill they can get from the users.

> PostgreSQL runs on numerous systems, and in order to do what you are
> proposing, it would be necessary to play system favorites.
>
> -> Configuration systems are inherently platform-specific.
>
This is true. But a large part of a configuration system could be made
platform independent. If a good modular configuration system was designed
and maintained by the PostgreSQL community, I'm pretty sure the platform
independent parts of it would see the light of day pretty quickly.

Kind regards,

Thomas Hallgren

On Sun, Apr 25, 2004 at 05:15:19PM -0400, pgsql(at)mohawksoft(dot)com wrote:
> (5) Programming languages. We need to make a programming language standard
> in PostgreSQL. plpgsql is good, but isn't someone working on a Java
> language. That would be pretty slick.

If there's going to be a single standard language, I strongly believe it
should be plpgsql. Any other language means that you have to find
something that someone else knows or is willing to learn, whereas anyone
using a database already knows SQL. plpgsql is simply an extension of
SQL, and is trivial for anyone who's worked with any other database
procedural languages to pickup. Asking a DBA to learn java or perl or
PHP is asking a lot.

If anything I'd like to see more features brought into plpgsql, like
packages (ala Oracle).
--
Jim C. Nasby, Database Consultant jim(at)nasby(dot)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?"

> In an attempt to throw the authorities off his trail, pgsql(at)mohawksoft(dot)com
> transmitted:
>> Is anyone really ready for this sort of commitment?
>
> By that, I presume you mean...
>
> "Are people prepared to stop working on the doubtless useful things
> that they are working on in favor of spending their time instead on
> this set of marketing-oriented systems integration tasks?"
>
> I think the answer to that is likely a pretty clear NO.

That's sort of the question, isn't it? Bruce asked what can "we" learn
from MySQL. Well, I've put forth an argument, right or wrong, its my
opinion. If there is a concensus that the PostgreSQL team wants to
increase user numbers, it is obvious, as evidenced by MySQL, it isn't only
about features.

The "marketing-oriented systems integration tasks" are arguably *more*
important than minor improvements to attain this goal.

>
> PostgreSQL runs on numerous systems, and in order to do what you are
> proposing, it would be necessary to play system favorites.

>
> -> Configuration systems are inherently platform-specific.

Not all that much, java setup programs or a Samba SWAT like program could
go a LONG way to improving configurability without suffering platform
snobbery.

>
> -> PL/Java is well and interesting, but requires a barrel of non-free
> software, which makes installation and configuration anything but
> "slick."
>
> There is _not_ going to be a "Product Management" group any time soon
> that will turn around PostgreSQL into being a marketing-driven
> project.

No one is saying "Market-driven project," but you must admit, some market
savvy would be helpful if you want to get more users.

[snip]

You know, there were some questions put out to the group wondering how to
get more users. You may disagree with my assessment, that's fine, I don't
want to have any hard feelings, but I think your tone speaks volumes about
why PostgreSQL regularly gets ignored. While it is better than MySQL in
almost every metric, it has fewer users than it should. The question is
why. I took a bit of time and effort to explain why I think this is so,
outline a number of steps that may help.

If getting more users is something that "we" want to do. Then "we" need to
think about what it is "we" need to do. "We" need to understand that "we"
need to do things we may not feel like doing for success. I may be
completely wrong in every sentence I wrote, but lets discuss why I may be
wrong, lets discuss what is the right way to do it, or lastly, lets decide
that it isn't important to get more users, but don't just say "you can't."

> On Sun, Apr 25, 2004 at 05:15:19PM -0400, pgsql(at)mohawksoft(dot)com wrote:
>> (5) Programming languages. We need to make a programming language
>> standard
>> in PostgreSQL. plpgsql is good, but isn't someone working on a Java
>> language. That would be pretty slick.
>
> If there's going to be a single standard language, I strongly believe it
> should be plpgsql. Any other language means that you have to find
> something that someone else knows or is willing to learn, whereas anyone
> using a database already knows SQL. plpgsql is simply an extension of
> SQL, and is trivial for anyone who's worked with any other database
> procedural languages to pickup. Asking a DBA to learn java or perl or
> PHP is asking a lot.
>
> If anything I'd like to see more features brought into plpgsql, like
> packages (ala Oracle).

Sorry, by standard, I meant installed by default, not to the exclusion of
all else.

pgsql(at)mohawksoft(dot)com wrote:
> If we want to make PostgreSQL a wildly popular product, there will be
> some pain. There should be a "Product Management" group. The
> leader(s) of this group should be chosen carefully, as he (they) must
> be free to define what PostgreSQL is. They must have a good feel for
> product development and understanding of the underlying technology,
> but not be so techie that we don't address the issues intended. They
> must be able to rally the troops and direct development efforts.
> Lastly, he (they) must have the confidence of the core hackers, as it
> is likely that there will be disagreements with the direction of
> PostgreSQL, and it wouldn't work if "Product Management" couldn't
> actually manage what the product was because nobody listened.

I agree with this, more or less. The lack of leadership that
coordinates all activities actively is really missing. Unfortunately,
I believe we are already in a state of fragmentation where setting up
something like this is no longer possible. What the end user sees as a
PostgreSQL system is brought to them by nearly a dozen different groups
nowadays. And the server group can no longer count on having a
stronger position to pull them all together. The only option to
achieve what you want soon is to market your own product.

Just a reflection from someone who has not been following PostgreSQL that
long...

I think you provide excellent leadership and keep a firm grip on the core
PostgreSQL server. Moving stuff out to Gborg and the discussion regarding
contrib tells me that you want to keep it that way. As I'm a firm beliver in
separation of concern and modularization, I really like that move. The
server group must concentrate on the server.

PosgreSQL is much more than just a server though. Something can be done that
would bring order to the current chaos and make the fragementation a
positive thing. What I think is needed is an architecture that goes beyond
the server. An architecture endorsed by the PostgreSQL. It would of course
include the semantics needed to create and link a plugin but it wouldn't
stop there. A very important feature would be packaging and deployment
(installers etc.). Another would be administration.

The architecture I have in mind *must* be endorsed and controlled by
PostgreSQL. It cannot be delivered by a freestanding group. Still, it's not
core server stuff. This is the means by which PostgreSQL would (re)gain
leadership of the whole thing. You don't need managers, you need a broader
component architecure.

My perception is that you need to somehow fork your efforts and look beyond
the core server horizon. A don't think it's too late. I'm convinced that
everyone that creates products that integrates with PostgreSQL would be more
than happy to comply (and make additions to) a common architecture if it
would help PostgreSQL to get a wider acceptance.

In short,
You have a great leverage. It's just a matter of using it the right way.

Kind regards,

Thomas Hallgren

"Peter Eisentraut" <peter_e(at)gmx(dot)net> wrote in message
news:200404262146(dot)54078(dot)peter_e(at)gmx(dot)net(dot)(dot)(dot)
> pgsql(at)mohawksoft(dot)com wrote:
> > If we want to make PostgreSQL a wildly popular product, there will be
> > some pain. There should be a "Product Management" group. The
> > leader(s) of this group should be chosen carefully, as he (they) must
> > be free to define what PostgreSQL is. They must have a good feel for
> > product development and understanding of the underlying technology,
> > but not be so techie that we don't address the issues intended. They
> > must be able to rally the troops and direct development efforts.
> > Lastly, he (they) must have the confidence of the core hackers, as it
> > is likely that there will be disagreements with the direction of
> > PostgreSQL, and it wouldn't work if "Product Management" couldn't
> > actually manage what the product was because nobody listened.
>
> I agree with this, more or less. The lack of leadership that
> coordinates all activities actively is really missing. Unfortunately,
> I believe we are already in a state of fragmentation where setting up
> something like this is no longer possible. What the end user sees as a
> PostgreSQL system is brought to them by nearly a dozen different groups
> nowadays. And the server group can no longer count on having a
> stronger position to pull them all together. The only option to
> achieve what you want soon is to market your own product.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>

pgsql(at)mohawksoft(dot)com wrote:
> (5) Programming languages. We need to make a programming language standard
> in PostgreSQL. plpgsql is good, but isn't someone working on a Java
> language. That would be pretty slick.

IMHO SQL/PSM would be the obvious choice for the standard
procedural language. Not only because it is part of the SQL
standard (ISO/IEC 9075-4:2003), but also because it is reasonably
intuitive and it is the same as what is implemented in DB2 (and
in MySQL 5 due sometime not so soon).
The only problem is that there is no PostgreSQL implementation.

Jochem

--
I don't get it
immigrants don't work
and steal our jobs
- Loesje

On Tue, 27 Apr 2004, Jochem van Dieten wrote:

> pgsql(at)mohawksoft(dot)com wrote:
> > (5) Programming languages. We need to make a programming language standard
> > in PostgreSQL. plpgsql is good, but isn't someone working on a Java
> > language. That would be pretty slick.
>
> IMHO SQL/PSM would be the obvious choice for the standard
> procedural language. Not only because it is part of the SQL
> standard (ISO/IEC 9075-4:2003), but also because it is reasonably
> intuitive and it is the same as what is implemented in DB2 (and
> in MySQL 5 due sometime not so soon).
> The only problem is that there is no PostgreSQL implementation.

While I can see heading in that direction, the lack of an implementation
makes this suggestion impractical. It will take time not just to
implement it, but to test it and debug it, and for it to reach "maturity."

PL/pgsql is mature and tested, has a great deal of code already written
for it, and has reached maturity. I'd say including it by default
represents little or no security risk, and increases the value, out of the
box, of postgresql for most folks while costing very little in terms of
wasted disk space etc...

I'm a great fan of Java. Still, I firmly believe that pgsql should be the
language of choice as the one included by default. I think many users
consider the ability to write functions and triggers using SQL intermixed
with the DDL statements (create function etc.) as the only natural way of
doing it. All other languages implies either mixing languages in the same
file or splitting declaration and implementation into separate files.

Java is excellent when you want to extend the language beyond what's
possible using SQL. Examples might include soundex or image recognition
algorithms. XML is another area where server side Java might play a
significant role. But that's all beyond core server functionality.

If anything, I'd rather see the JDBC and ODBC drivers reinstated in the
release. More than 56% of the PostgreSQL users (according to the poll) uses
JDBC today. ODBC is merely 18% but that might change significantly when the
native Win32 port is released. I might have missed something altogether
here, my apologies if that's the case, but looking at the coming 7.5
release, 75% of the users will be forced to download stuff from more than
one location just to get their basic stuff running.

Kind regards,

Thomas Hallgren

""scott.marlowe"" <scott(dot)marlowe(at)ihs(dot)com> wrote in message
news:Pine(dot)LNX(dot)4(dot)33(dot)0404271149070(dot)5967-100000(at)css120(dot)ihs(dot)com(dot)(dot)(dot)
> On Tue, 27 Apr 2004, Jochem van Dieten wrote:
>
> > pgsql(at)mohawksoft(dot)com wrote:
> > > (5) Programming languages. We need to make a programming language
standard
> > > in PostgreSQL. plpgsql is good, but isn't someone working on a Java
> > > language. That would be pretty slick.
> >
> > IMHO SQL/PSM would be the obvious choice for the standard
> > procedural language. Not only because it is part of the SQL
> > standard (ISO/IEC 9075-4:2003), but also because it is reasonably
> > intuitive and it is the same as what is implemented in DB2 (and
> > in MySQL 5 due sometime not so soon).
> > The only problem is that there is no PostgreSQL implementation.
>
> While I can see heading in that direction, the lack of an implementation
> makes this suggestion impractical. It will take time not just to
> implement it, but to test it and debug it, and for it to reach "maturity."
>
> PL/pgsql is mature and tested, has a great deal of code already written
> for it, and has reached maturity. I'd say including it by default
> represents little or no security risk, and increases the value, out of the
> box, of postgresql for most folks while costing very little in terms of
> wasted disk space etc...
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>

On Mon, Apr 26, 2004 at 02:31:27PM -0400, pgsql(at)mohawksoft(dot)com wrote:
> > On Sun, Apr 25, 2004 at 05:15:19PM -0400, pgsql(at)mohawksoft(dot)com wrote:
> >> (5) Programming languages. We need to make a programming language
> >> standard
> >> in PostgreSQL. plpgsql is good, but isn't someone working on a Java
> >> language. That would be pretty slick.
> >
> > If there's going to be a single standard language, I strongly believe it
> > should be plpgsql. Any other language means that you have to find
> > something that someone else knows or is willing to learn, whereas anyone
> > using a database already knows SQL. plpgsql is simply an extension of
> > SQL, and is trivial for anyone who's worked with any other database
> > procedural languages to pickup. Asking a DBA to learn java or perl or
> > PHP is asking a lot.
> >
> > If anything I'd like to see more features brought into plpgsql, like
> > packages (ala Oracle).
>
> Sorry, by standard, I meant installed by default, not to the exclusion of
> all else.

I would still argue that if any language should be installed by default
it should be plpgsql and not java. As I mentioned, everyone using a
database already knows SQL; not nearly as many know java.
--
Jim C. Nasby, Database Consultant jim(at)nasby(dot)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?"

Jim C. Nasby wrote:

>
>I would still argue that if any language should be installed by default
>it should be plpgsql and not java. As I mentioned, everyone using a
>database already knows SQL; not nearly as many know java.
>
>

I know both. :-).

Seriously - I'd like to raise my voice in favor of installing plpgsql in
template1 by default. I haven't heard any good reason not to (nor even a
bad reason).

cheers

andrew

>>
>>
>
> I know both. :-).
>
> Seriously - I'd like to raise my voice in favor of installing plpgsql in
> template1 by default. I haven't heard any good reason not to (nor even a
> bad reason).
>

If we install plPGSQL by default, we should install any other pl
language that was configured at runtime by default as well. This
includes plPerl, plTCL, and plPython.

Of course only if they were compiled in, but sense they are a part of
the core distribution we shouldn't favor one over the other.

Personally, plpgSQL is only useful to those who are coming from Oracle.
People are more likely to be comfortable with plPython or plPerl than
plpgSQL.

Sincerely,

Joshua D. Drake

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

jim(at)nasby(dot)net ("Jim C. Nasby") writes:
> I would still argue that if any language should be installed by
> default it should be plpgsql and not java. As I mentioned, everyone
> using a database already knows SQL; not nearly as many know java.

A vital factor is indeed that pl/pgsql does not require require
importing extra APIs to access the database.
--
(format nil "~S(at)~S" "cbbrowne" "ntlug.org")
http://www3.sympatico.ca/cbbrowne/sgml.html
Sleep is a poor subsititute for caffeine. -Pat Dughi

On Tue, Apr 27, 2004 at 01:14:08PM -0700, Joshua D. Drake wrote:
> If we install plPGSQL by default, we should install any other pl
> language that was configured at runtime by default as well. This
> includes plPerl, plTCL, and plPython.
That certainly makes sense.

> Of course only if they were compiled in, but sense they are a part of
> the core distribution we shouldn't favor one over the other.
>
> Personally, plpgSQL is only useful to those who are coming from Oracle.
> People are more likely to be comfortable with plPython or plPerl than
> plpgSQL.

I'll beg to differ. :) I started using PostgreSQL well over a year
before Oracle. plpgSQL is SQL based; that's the key difference. I can't
back this up, but I'd bet that the majority of professional DBAs would
be far more comfortable in plpgSQL than in plPython or plPerl because
they deal with SQL day in and day out, while they probably only use
other languages for scripting (java being one possible exception).

Ultimately I think it's fine that PostgreSQL doesn't favor any of the
languages, but I think plpgSQL would be the only logical one to favor if
that was going to be the case. But then again, I'm a professional DBA; I
suspect someone who is more of a coder than a DBA might disagree.
--
Jim C. Nasby, Database Consultant jim(at)nasby(dot)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?"

Joshua D. Drake wrote:

>
> If we install plPGSQL by default, we should install any other pl
> language that was configured at runtime by default as well. This
> includes plPerl, plTCL, and plPython.
>
> Of course only if they were compiled in, but sense they are a part of
> the core distribution we shouldn't favor one over the other.
>
> Personally, plpgSQL is only useful to those who are coming from Oracle.
> People are more likely to be comfortable with plPython or plPerl than
> plpgSQL.
>

Joshua - as you know I'm a perl fan. But plpgsql is special, for a
number of reasons, not least that it doesn't require any extra
libraries, and should be installable on every postgresql system.

I know people hate playing favourites, but you can take that too far.

cheers

andrew

> If anything, I'd rather see the JDBC and ODBC drivers reinstated in the
> release. More than 56% of the PostgreSQL users (according to the poll) uses
> JDBC today. ODBC is merely 18% but that might change significantly when the
> native Win32 port is released. I might have missed something altogether
> here, my apologies if that's the case, but looking at the coming 7.5
> release, 75% of the users will be forced to download stuff from more than
> one location just to get their basic stuff running.

Note that MySQL doesn't bundle them, but they are CLEARLY available for
download on their site on all places where MySQL itself is available for
download.

Chris

Centuries ago, Nostradamus foresaw when jd(at)commandprompt(dot)com ("Joshua D. Drake") would write:
> Personally, plpgSQL is only useful to those who are coming from
> Oracle. People are more likely to be comfortable with plPython or
> plPerl than plpgSQL.

I beg to differ.

In order to use pl/Python or pl/Perl to manipulate data in the
database, I have to go and find an SPI module.

With pl/pgsql, all I need to do is to directly present the SQL
queries.

The flip side, of course, is that Perl and Python provide nice idioms
for fiddling with text that are much nicer than clumsy usages of
substr() in pl/pgsql.

I'd rather do complex text validation in Perl, but write code that
does "table stuff" in pl/pgsql.

That is indeed the /exact/ approach I have taken in using stored
procedures for data conversions; a mix of the both, using each to
harness its respective strengths.
--
let name="cbbrowne" and tld="cbbrowne.com" in name ^ "@" ^ tld;;
http://www3.sympatico.ca/cbbrowne/lsf.html
'Mounten' wird fuer drei Dinge benutzt: 'Aufsitzen' auf Pferde,
'einklinken' von Festplatten in Dateisysteme, und, nun, 'besteigen'
beim Sex.

Joshua D. Drake wrote:

>> I know both. :-).
>>
>> Seriously - I'd like to raise my voice in favor of installing plpgsql
>> in template1 by default. I haven't heard any good reason not to (nor
>> even a bad reason).
>>
>
> If we install plPGSQL by default, we should install any other pl
> language that was configured at runtime by default as well. This
> includes plPerl, plTCL, and plPython.
>
> Of course only if they were compiled in, but sense they are a part of
> the core distribution we shouldn't favor one over the other.
>
> Personally, plpgSQL is only useful to those who are coming from Oracle.
> People are more likely to be comfortable with plPython or plPerl than
> plpgSQL.

I disagree. I know python and perl and I have never touched Oracle, but
I find plpgsql to be more useful than the others. Mainly because
(1) It is strongly typed, has all the same types as postgresql itself,
consistent support for NULLS, etc.

(2) Upon a casual read of the docs I couldn't figure out how to read any
values from the database other than what was passed into the
pl{perl|python|php} function. I.e., how do you run a select? What client
libraries do you use? Maybe the others just need better docs.

Paul Tillotson

Joshua D. Drake wrote:

> Personally, plpgSQL is only useful to those who are coming from Oracle.
> People are more likely to be comfortable with plPython or plPerl than
> plpgSQL.

Well that was not true for my, I started using postgres and plpgsql
not because I knew Oracle ( I don't know it ).

plpgsql is more close to postgres then plPython or plPerl, and after
all is nearest SQL then plPtyhton or plPerl so a DBA find it more
confortable then others languages.

my two cents.

Regards
Gaetano Mendola

>
> plpgsql is more close to postgres then plPython or plPerl, and after
> all is nearest SQL then plPtyhton or plPerl so a DBA find it more
> confortable then others languages.

DBA probably... programmer? Doubtful. The majority of people that I run
into that are using PostgreSQL are not DBA's. They are programmers
trying to do it a better way. Providing plPerl or plPython etc... allows
them to stay in a native and productive environment.

Sincerely,

Joshua D. Drake

>
>
> my two cents.
>
>
>
> Regards
> Gaetano Mendola
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html

--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd(at)commandprompt(dot)com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL

Joshua D. Drake wrote:

>>
>> plpgsql is more close to postgres then plPython or plPerl, and after
>> all is nearest SQL then plPtyhton or plPerl so a DBA find it more
>> confortable then others languages.
>
>
> DBA probably... programmer? Doubtful. The majority of people that I run
> into that are using PostgreSQL are not DBA's. They are programmers
> trying to do it a better way. Providing plPerl or plPython etc... allows
> them to stay in a native and productive environment.

True, but a good DBA have to check each single store procedure and view that
other programmers write, see tuning techics that programmers are not aware of
( see select max(id) from foo; optimized with a order by + limit 1 ).

Regards
Gaetano Mendola