Usability, MySQL, Postgresql.org, gborg, contrib, etc.

In an attempt to throw the authorities off his trail, pgsql@mohawksoft.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@~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@acm.org> wrote in message
news:m3ekqbaec5.fsf@wolfe.cbbrowne.com...

In an attempt to throw the authorities off his trail, pgsql@mohawksoft.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

pgsql@mohawksoft.com wrote:

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

I've found webmin to be pretty good swat type tool...it's lacking some
things to be a full postgres administration system, but I think they
have the right idea...

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

Personally, I like the idea of plphp better. I haven't used either,
though. plgsql will always have value in converting oracle deployments,
so it is truly hard to standardize on a favorite here.

I think the latest versions of pgAdmin are just awesome. I never used
to like it very much, but it really is great software. I think any
effort expended on beefing that project up is not wasted.

Merlin

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.

Well, NO, not a chance.

As one of the de-facto heads of our Advocacy group, let me say "you've got to
be kidding."

MySQL is a private closed-shop software manufacturer who uses the GPL as one
of their methods of distribution. They are not a "real" open source project
-- they are a private, commercial, for-profit software company.

We are not. We are a open, 100% voluntary community of contributing
developers and support volunteers. Nobody is going to take orders from a
"Product Manager", that's a position for paid software products departments.
It would be horribly inappropriate for PostgreSQL, and would destroy
everything that has made us successful to date. You can't give orders to
volunteers.

You're statement that "all other systems" have a Product Manager is also
wildly inaccurate. I think you're thinking of MySQL and Mozilla only.
Heck, even OpenOffice.org doesn't have a Product Manager, and that is a
Sun-sponsored project. Let alone, say, emacs. Or Linux.

--
Josh Berkus
Aglio Database Solutions
San Francisco

On Sun, Apr 25, 2004 at 05:15:19PM -0400, pgsql@mohawksoft.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@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?"

In an attempt to throw the authorities off his trail, pgsql@mohawksoft.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@mohawksoft.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.

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.

Well, NO, not a chance.

As one of the de-facto heads of our Advocacy group, let me say "you've got
to
be kidding."

I don't think so, let me explain below.

MySQL is a private closed-shop software manufacturer who uses the GPL as
one
of their methods of distribution. They are not a "real" open source
project
-- they are a private, commercial, for-profit software company.

I agree, I don't like MySQL all that much.

We are not. We are a open, 100% voluntary community of contributing
developers and support volunteers. Nobody is going to take orders from a
"Product Manager", that's a position for paid software products
departments.
It would be horribly inappropriate for PostgreSQL, and would destroy
everything that has made us successful to date. You can't give orders to
volunteers.

It depends on the volunteers. Some are useless at taking orders, this is
true, others, however, are very welcoming to direction. It depends in the
individual. Lastly, Bruce, Tom, Peter, and others are very didicated to
PostgreSQL. If a real case can be made for a feature, I'm sure they are
reasonable enough to see that and grudgingly implement it. Someone,
however, has to keep an eye on that ball.

You're statement that "all other systems" have a Product Manager is also
wildly inaccurate. I think you're thinking of MySQL and Mozilla only.
Heck, even OpenOffice.org doesn't have a Product Manager, and that is a
Sun-sponsored project. Let alone, say, emacs. Or Linux.

Linux has Linus, he has a very good eye in the market forces. Emacs, is a
non-entity outside UNIX hard core UNIX guys. OpenOffice is very much
managed by Sun.

Hey,

First of all, who is this? I don't recognize the e-mail, and you haven't
been signing any of your posts.

true, others, however, are very welcoming to direction.

AFAIK, this includes none of our major code contributors. So all you're
really talking about is manipulating the TODO list. You can't tell
programmers what to code unless you're paying them.

It depends in the
individual. Lastly, Bruce, Tom, Peter, and others are very didicated to
PostgreSQL. If a real case can be made for a feature, I'm sure they are
reasonable enough to see that and grudgingly implement it. Someone,
however, has to keep an eye on that ball.

Yes, but they don't need a title to do so. Nor is there any reason for this
to be one person. In fact, you've just described one of the reason for the
Core's existance -- and even the Core defers to the consensus of decision on
this forum about which features to implement and how.

Now, if you're arguing that we could use a more cohesive, readable roadmap?
Sure! Want to prepare one? I can even help you find out what's under
development and what's not likely any time soon.

Linux has Linus, he has a very good eye in the market forces.

Uh-huh. So? That still doesn't make him a "product manager".

OpenOffice is very much
managed by Sun.

I used to be a Project Lead for OpenOffice.org. I think the amount of
consensus and compromise, and the extent to which the Community Council and
the Project Leads govern the project, would surprise you.

Overall, I've not seen you present any coherent arguments as to:
1) why we need a new person with a title for marketing stuff;
2) what this person would be doing that's not already covered by existing
groups;
3) how this person would be able to accomplish their "job"; and
4) who this person would be.

As far as I'm concerned, we need use titles here only if it lends the entitled
some kind of authority with the outside world that helps them on their
volunteer projects (Robert Bernier, "Business Intelligence Analyst", is a
good example of a good use of titles -- that one convinces companies that he
approaches about case studies that he's for real). Titles are not at all
useful *inside* the community, we don't need them.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

Hey,

First of all, who is this? I don't recognize the e-mail, and you haven't
been signing any of your posts.

I've been posting on hackers on and off for a few years. My name is Mark.

true, others, however, are very welcoming to direction.

AFAIK, this includes none of our major code contributors. So all you're
really talking about is manipulating the TODO list. You can't tell
programmers what to code unless you're paying them.

Yes and no. People can and do what's needed when it is clearly
articulated. What is lacking is a clear direction WRT marketing.

It depends in the
individual. Lastly, Bruce, Tom, Peter, and others are very didicated to
PostgreSQL. If a real case can be made for a feature, I'm sure they are
reasonable enough to see that and grudgingly implement it. Someone,
however, has to keep an eye on that ball.

Yes, but they don't need a title to do so. Nor is there any reason for
this
to be one person. In fact, you've just described one of the reason for
the
Core's existance -- and even the Core defers to the consensus of decision
on
this forum about which features to implement and how.

I think I am talking about something different. In a company, the core
team would be the CTO. I think some entity, one or more people, needs to
define the product. Typically this is marketing and product management.

Now, if you're arguing that we could use a more cohesive, readable
roadmap?
Sure! Want to prepare one? I can even help you find out what's under
development and what's not likely any time soon.

Absolutely, but it would be meaningless if no body listens.

Linux has Linus, he has a very good eye in the market forces.

Uh-huh. So? That still doesn't make him a "product manager".

Maybe I've overstated my case, by management I mean the small 'm' not the
big 'M'

OpenOffice is very much
managed by Sun.

I used to be a Project Lead for OpenOffice.org.

Very cool. It is a great project/product.

I think the amount of
consensus and compromise, and the extent to which the Community Council
and
the Project Leads govern the project, would surprise you.

No it wouldn't.

Overall, I've not seen you present any coherent arguments as to:
1) why we need a new person with a title for marketing stuff;

The why is that there is no real entity doing so.

2) what this person would be doing that's not already covered by existing
groups;

All the groups, with the exception of advocacy, are "here's what we are
building" and "here's a bug" groups. There is planning on hackers, but it
is almost purely technical. Marketing features do no often get a
reasonable hearing.

3) how this person would be able to accomplish their "job";

I think that a talented manager could make the case for certain features.

4) who this person would be.

We recrute like a company does.

As far as I'm concerned, we need use titles here only if it lends the
entitled
some kind of authority with the outside world that helps them on their
volunteer projects (Robert Bernier, "Business Intelligence Analyst", is a
good example of a good use of titles -- that one convinces companies that
he
approaches about case studies that he's for real). Titles are not at all
useful *inside* the community, we don't need them.

I'm not trying to change the dynamic significantly, but I think, again if
increasing usership is important, that some market driven lessons need to
be learned.

pgsql@mohawksoft.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.

Hi, Mark,

Yes, I've seen your e-mails around. You should use a sig, though, they're
easy to create.

I think I am talking about something different. In a company, the core
team would be the CTO. I think some entity, one or more people, needs to
define the product. Typically this is marketing and product management.

But, as Peter reminds me all the time, we're not a company. ;-)

The why is that there is no real entity doing so.

2) what this person would be doing that's not already covered by existing
groups;

All the groups, with the exception of advocacy, are "here's what we are
building" and "here's a bug" groups. There is planning on hackers, but it
is almost purely technical. Marketing features do no often get a
reasonable hearing.

That's not an argument for not using existing apparatus. What you've
persuaded me is that you should:
a) join the Advocacy group;
b) galvanize people around developing a coherent marketing plan;
c) Lead a crew of volunteers and follow through on that process until the plan
is ready for comments by Core and Hackers,
d) stick around for the arguments and revisions

That's what we *need*. We don't need a volunteer with a title who might or
might not do any of the above.

I'm particulary struck by the fact that you chose to inaugurate this
discussion on Hackers, instead of Advocacy where it would have been more
appropriate and where more of the *existing* marketing volunteers would have
participated. At this point, I'd have to forward the whole thing to transfer
it ...

I think that a talented manager could make the case for certain features.

So? So could any community member with a good grasp of database engineering
and an ability to write persuasive e-mails.

4) who this person would be.

We recrute like a company does.

Um, and pay them with what? Cowrie shells?

--
-Josh Berkus
Aglio Database Solutions
San Francisco

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@gmx.net> wrote in message
news:200404262146.54078.peter_e@gmx.net...

pgsql@mohawksoft.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@mohawksoft.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...

On Mon, 26 Apr 2004, Josh Berkus wrote:

I think that a talented manager could make the case for certain features.

So? So could any community member with a good grasp of database engineering
and an ability to write persuasive e-mails.

I'd like to inject here that I was the one who started the whole argument
over date style enforcement about a year ago. It was a bit of a slog at
first, but I felt my input was good, and the cause was just :-).

Because of that discussion, PostgreSQL accpeting dates like

2004-31-03 and turning them into 2004-03-31 on the fly stopped. as did
postgresql accepting a date like 03/31/2004 and turning it into 31/03/2004
when it was set to accept Euro style dates.

I am not a PostgreSQL hacker, just a user. My input made the difference.
No title needed. What PostgreSQL needs more of is caring users who can
spot bugs / misbehaviours, make a decent argument about it, and maybe even
a patch or two. We're way more short on indians than chiefs in my
opinion.

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.marlowe@ihs.com> wrote in message
news:Pine.LNX.4.33.0404271149070.5967-100000@css120.ihs.com...

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

pgsql@mohawksoft.com wrote:

(5) Programming languages. We need to make a programming language

standard

On Mon, Apr 26, 2004 at 02:31:27PM -0400, pgsql@mohawksoft.com wrote:

On Sun, Apr 25, 2004 at 05:15:19PM -0400, pgsql@mohawksoft.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@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?"

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

-----Original Message-----
From: Andrew Dunstan [mailto:andrew@dunslane.net]
Sent: Tuesday, April 27, 2004 12:55 PM
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Usability, MySQL, Postgresql.org,
gborg, contrib,

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

I offered the same opinion a while back, and was told that plpgsql is a
security hole.

jim@nasby.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@~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:32:44PM -0700, Dann Corbit wrote:

From: Andrew Dunstan [mailto:andrew@dunslane.net]

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

I offered the same opinion a while back, and was told that plpgsql is a
security hole.

Huh? Maybe we should fix it instead, because it's trusted.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Coge la flor que hoy nace alegre, ufana. �Qui�n sabe si nacera otra ma�ana?"

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@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?"

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

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

It has to work with older dumps that will try to recreate pl/pgsql
themselves explicitly.

I offered the same opinion a while back, and was told that plpgsql is a
security hole.

The we can make it not have USAGE privileges to public by default??

Chris

Centuries ago, Nostradamus foresaw when jd@commandprompt.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

On Wed, 28 Apr 2004, Christopher Kings-Lynne wrote:

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

It has to work with older dumps that will try to recreate pl/pgsql
themselves explicitly.

This wouldn't be a problem, though, would it? The dumps don't run inside a
transaction so after the failure to create PL/PgSQL because it already
exists, the import would continue as before.

Jon

Jon Jensen wrote:

On Wed, 28 Apr 2004, Christopher Kings-Lynne wrote:

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

It has to work with older dumps that will try to recreate pl/pgsql
themselves explicitly.

This wouldn't be a problem, though, would it? The dumps don't run inside a
transaction so after the failure to create PL/PgSQL because it already
exists, the import would continue as before.

We could make it somewhat cleaner by having a flag on pg_dump that
allowed/suppressed the language creation for plpgsql.

cheers

andrew

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@commandprompt.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