RFC: PostgreSQL Add-On Network

On Thu, Jan 7, 2010 at 8:07 PM, David E. Wheeler <david@kineticode.com> wrote:

Hackers,

I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL extensions. I've tried to closely follow the [CPAN philosophy][] to come up with a plan that requires a minimum-work implementation that builds on the existing PostgreSQL tools and the examples of the [CPAN][] and [JSAN][]. My hope is that it's full of [JFDI][]! I would be very grateful for feedback and suggestions.

Whilst the aim is a noble one, glossing over 'it won't work on
Windows' which is by far our most popular platform these days seems
incredibly short sighted, and liable to lead to an endless stream of
'why doesn't this work' questions. It also does the module authors no
favours, by excluding 50%+ of their potential audience, and frankly,
isn't the way this project generally works.

We have discussed this sort of facility at previous developer
meetings, and as I recall came to the conclusion that we need to have
the ability to distribute pre-built binaries, not just source code as
virtually no Windows users are ever going to have a build environment
setup. Similarly, neither are Mac users, if they didn't install XCode.

We also discussed extension management at the DBMS level, which I
believe Dimitri was working on in his spare time. You should look at
what he's been doing.

Finally, don't write the client in Perl. Again, that's of no use to
most Windows users. C will work on all platforms from the outset, with
no dependencies required. Of course, the server side doesn't matter.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

On Thu, 2010-01-07 at 20:36 +0000, Dave Page wrote:

On Thu, Jan 7, 2010 at 8:07 PM, David E. Wheeler <david@kineticode.com> wrote:

Hackers,

I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL extensions. I've tried to closely follow the [CPAN philosophy][] to come up with a plan that requires a minimum-work implementation that builds on the existing PostgreSQL tools and the examples of the [CPAN][] and [JSAN][]. My hope is that it's full of [JFDI][]! I would be very grateful for feedback and suggestions.

Whilst the aim is a noble one, glossing over 'it won't work on
Windows' which is by far our most popular platform these days

Although I understand your point, this is debatable to the point of a
pointless point :P. The reason it seems like the most popular is that
the only way to get the windows version is to download it from .Org/EDB.
Linux/FreeBSD already has it in their own repositories.

I do believe that we need to support windows, but not everything will.
That is just the nature of it.

Joshua D. Drake

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.

On Thu, Jan 7, 2010 at 21:42, Joshua D. Drake <jd@commandprompt.com> wrote:

On Thu, 2010-01-07 at 20:36 +0000, Dave Page wrote:

On Thu, Jan 7, 2010 at 8:07 PM, David E. Wheeler <david@kineticode.com> wrote:

Hackers,

I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL extensions. I've tried to closely follow the [CPAN philosophy][] to come up with a plan that requires a minimum-work implementation that builds on the existing PostgreSQL tools and the examples of the [CPAN][] and [JSAN][]. My hope is that it's full of [JFDI][]! I would be very grateful for feedback and suggestions.

Whilst the aim is a noble one, glossing over 'it won't work on
Windows' which is by far our most popular platform these days

Although I understand your point, this is debatable to the point of a
pointless point :P. The reason it seems like the most popular is that
the only way to get the windows version is to download it from .Org/EDB.
Linux/FreeBSD already has it in their own repositories.

If you count production servers, it's certainly going to be more
Linux/BSD. But if you start counting developer machines, Windows gets
ahead quickly. And then start looking at all the point-of-sales
systems etc that come with an embedded PostgreSQL - the vast majority
of those (unfortunately) run on Windows.

It's not the biggest databases. But it's the most.

And particularly something like this needs to work well on the
developers machines, or things won't get through the door.

I do believe that we need to support windows, but not everything will.
That is just the nature of it.

True. But if it's something that's infrastructure, it should work on
all major platforms. This certainly includes Windows.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

David E. Wheeler wrote:

Hackers,

I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL
extensions. I've tried to closely follow the [CPAN philosophy][] to
come up with a plan that requires a minimum-work implementation that
builds on the existing PostgreSQL tools and the examples of the [CPAN][]
and [JSAN][]. My hope is that it's full of [JFDI][]! I would be very
grateful for feedback and suggestions.

[plan]: http://wiki.postgresql.org/wiki/PGAN
[CPAN philosophy]: http://use.perl.org/article.pl?sid=02/11/12/1616209
[CPAN]: http://cpan.org/
[JSAN]: http://www.openjsan.org
[JFDI]: http://acronyms.thefreedictionary.com/JFDI

Not enough brackets. ;-)

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Dave,

Whilst the aim is a noble one, glossing over 'it won't work on
Windows' which is by far our most popular platform these days seems
incredibly short sighted, and liable to lead to an endless stream of
'why doesn't this work' questions. It also does the module authors no
favours, by excluding 50%+ of their potential audience, and frankly,
isn't the way this project generally works.

But why is that *this* project's job to solve? It's already the case
that contrib modules (or PostgreSQL) are not buildable on Windows in an
automated fashion. And that Windows does not ship with developer tools.
That's not PGAN's fault.

We have discussed this sort of facility at previous developer
meetings, and as I recall came to the conclusion that we need to have
the ability to distribute pre-built binaries, not just source code as
virtually no Windows users are ever going to have a build environment
setup. Similarly, neither are Mac users, if they didn't install XCode.

Binary distributions are a good idea, for v2+. The problem with
requiring that is then you're effectively requiring every module author,
or a well-funded 3rd party, to have a huge build farm capable of
building binaries for a wide variety of platforms and PostgresQL
versions. Requiring that from the outset is a good way to ensure that
nobody *ever* builds an extension management platform.

If someone is available to provide that build platform, then it's a
different story, but I don't know of anyone with those resources right
now. It's *already* the case that Windows users have no access to the
temporal, prefix or pgmemcache projects without Visual C++ and some
jiggery-pokery. How does PGAN make them worse off?

We also discussed extension management at the DBMS level, which I
believe Dimitri was working on in his spare time. You should look at
what he's been doing.

This is designed to be complimentary to Dimitri's project, if you read
the wiki page.

Finally, don't write the client in Perl. Again, that's of no use to
most Windows users. C will work on all platforms from the outset, with
no dependencies required. Of course, the server side doesn't matter.

It would make sense to build a C version when the other issues with
supporting Windows are solved. At that point, the specification for the
client should be well-worn enough to make doing the C version not a halt
to further development. Until then, it doesn't matter.

What I'm getting from your e-mail, Dave, is "If it doesn't solve all
problems for everyone in the world from Day 1, it's not worth doing."
It's my experience that the way to get OSS software that works is to
build a little bit at a time, each delivery of which is useful to some
people and solves some problems. Projects which attempt to paint the
whole world never get anywhere.

David's proposal is designed to be something which he can get done *this
year*, possibly before 8.5 is released, and be built on later. It'll be
useful to a substantial number of our users, and will be an improvement
on what we have now.

--Josh Berkus

On Jan 7, 2010, at 12:36 PM, Dave Page wrote:

Whilst the aim is a noble one, glossing over 'it won't work on
Windows' which is by far our most popular platform these days seems
incredibly short sighted, and liable to lead to an endless stream of
'why doesn't this work' questions. It also does the module authors no
favours, by excluding 50%+ of their potential audience, and frankly,
isn't the way this project generally works.

That's orthogonal to the development of PGAN. The PGAN client will depend on PGXS to do the installing. If the core implements something that works better on Windows, the PGAN client will use it.

We have discussed this sort of facility at previous developer
meetings, and as I recall came to the conclusion that we need to have
the ability to distribute pre-built binaries, not just source code as
virtually no Windows users are ever going to have a build environment
setup. Similarly, neither are Mac users, if they didn't install XCode.

It's no hardship to install XCode. People do it for Perl/CPAN installs all the time.

We also discussed extension management at the DBMS level, which I
believe Dimitri was working on in his spare time. You should look at
what he's been doing.

He and I have discussed it. As I wrote in the proposal, when extensions get in, the PGAN client will be updated as appropriate to support them.

Finally, don't write the client in Perl. Again, that's of no use to
most Windows users. C will work on all platforms from the outset, with
no dependencies required. Of course, the server side doesn't matter.

I'll do it in Perl because:

1. It's what I know.
2. There's a lot to draw on already (CPAN.pm, JSAN::Client, CPANPLUS)
3. JFDI.

The nice thing is that anyone will be able to write a client if they want it in some other language.

Best,

David

On Thu, Jan 7, 2010 at 9:22 PM, Josh Berkus <josh@agliodbs.com> wrote:

Dave,

Whilst the aim is a noble one, glossing over 'it won't work on
Windows' which is by far our most popular platform these days seems
incredibly short sighted, and liable to lead to an endless stream of
'why doesn't this work' questions. It also does the module authors no
favours, by excluding 50%+ of their potential audience, and frankly,
isn't the way this project generally works.

But why is that *this* project's job to solve?

Because if we (PostgreSQL) are going to support this effort, then it
should not ignore such a huge percentage of our installation base.

 It's already the case
that contrib modules (or PostgreSQL) are not buildable on Windows in an
automated fashion.  And that Windows does not ship with developer tools.
 That's not PGAN's fault.

No. But that's why we built binaries for people to use. That's pretty
much my point.

Binary distributions are a good idea, for v2+.  The problem with
requiring that is then you're effectively requiring every module author,
or a well-funded 3rd party, to have a huge build farm capable of
building binaries for a wide variety of platforms and PostgresQL
versions.   Requiring that from the outset is a good way to ensure that
nobody *ever* builds an extension management platform.

No, I'm suggesting the mechanism needs to support source and binary
distribution. For most *nix users, source will be fine. For Windows
binaries are required.

Building them is no problem - authors can easily use EC2 for which we
have an AMI pre-configured for next to no cost, can build on their own
platform, on a community provided system, or get a friend to do it.

We also discussed extension management at the DBMS level, which I
believe Dimitri was working on in his spare time. You should look at
what he's been doing.

This is designed to be complimentary to Dimitri's project, if you read
the wiki page.

Finally, don't write the client in Perl. Again, that's of no use to
most Windows users. C will work on all platforms from the outset, with
no dependencies required. Of course, the server side doesn't matter.

It would make sense to build a C version when the other issues with
supporting Windows are solved.  At that point, the specification for the
client should be well-worn enough to make doing the C version not a halt
to further development.  Until then, it doesn't matter.

So you have to rewrite the code. Seems like a waste of effort.

What I'm getting from your e-mail, Dave, is "If it doesn't solve all
problems for everyone in the world from Day 1, it's not worth doing."

No. The essence is, 'If you're going to do it in a way that will never
work for maybe 50% or more of PostgreSQL installations, then you have
fundamental design issues to overcome'.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

On Jan 7, 2010, at 1:31 PM, Dave Page wrote:

No, I'm suggesting the mechanism needs to support source and binary
distribution. For most *nix users, source will be fine. For Windows
binaries are required.

I would love to follow what Strawberry Perl has done to solve this problem. In 2.0.

Best,

David

Dave Page <dpage@pgadmin.org> writes:

We have discussed this sort of facility at previous developer
meetings, and as I recall came to the conclusion that we need to have
the ability to distribute pre-built binaries, not just source code as
virtually no Windows users are ever going to have a build environment
setup. Similarly, neither are Mac users, if they didn't install XCode.

And I think that's exactly why David and you are both right. The way I
see it, we need *both* a source level distribution infrastructure, which
David is proposing to implement under the PGAN name, and a binary one
too, which is implemented by distributions like debian, Fedora and the
like, and by Devrim when it comes to PGDG RPMs repos and… by you when we
talk about MacOSX and Windows binary distribution.

I think the aim of the PGAN should be to make it damn easy for binary
distributions to include whatever PGXS extension they whish, with about
no effort.

We also discussed extension management at the DBMS level, which I
believe Dimitri was working on in his spare time. You should look at
what he's been doing.

We've been talking about that together on IRC, and my only reserve here
ain't technical, as we already have a somewhat advanced notion of an
extension. What we miss is support for dump and restore, so my reserve
is that pushing the current system to point-and-clic users when it's not
ready to allow you to just pg_restore a dump when you installed any PGXS
extension (contribs included) is going to have us *lose* users, not gain
any.

Unfortunately I was overly optimistic last May when I though I could
reach a patch submission in the 8.5 cycle. I'd put it on too much work
on the day and no more free time with the required energy when my son is
so young (yes, that's a good problem to have). But still.

What I have been able to do is to determine what features to include in
a first extensions implementation, and proposing a syntax that no one
refused (after less successful attempts). Also the work remaining to be
done would represent easily a month of my evening and week-end time, and
maybe a Tom's morning. But he wouldn't have the fun of learning anything
new, and to paraphrase him, source contributors don't grow on trees :)

Anyway I've tried to summary it all (with some code perspective) in the
following wiki page:

http://wiki.postgresql.org/wiki/ExtensionPackaging

Essentially, it's all about coding a new backend function to execute
commands from a file on the server, in the spirit of \i for psql, say
e.g. pg_execute_commands_from_file('path/ to/file.sql'). It would not
send any result back to the client because you can only describe the
portal once for any given single query.

Then you need to add a catalog for holding the extensions metadata, like
the path of the install file, uninstall file, current version, upgrade
function, custom class if any, path of the setup file (GUCs).

And dependancies between extensions, and between a given extension and
what core provides too (plpgsql e.g., or major postgresql version too).

Now you can hack a CREATE EXTENSION command to fill-in the catalog, and
the commands INSTALL EXTENSION and DROP EXTENSION to execute the given
files. You have to invent a trick to be able to assign any SQL object
created while executing the install file a dependency entry targeting
the extension's catalog oid. As this is all done in a single given
backend, my guess is that a static variable holding the oid would be
enough, but you still have to touch all object creation code path.

You do *not* have to care about schema in any way *BUT* to prepend the
search_path with pg_extension just before executing the install
file. It's a new schema to provide in template databases, so that
extensions default to creating their objects there. This new schema
should be installed just before pg_catalog in the search_path in places
that search for objects from their non qualified name. Full stop on this
topic.

Oh and special bonus if CREATE EXTENSION, given a newer version of an
already installed extension, will register things so as to run the
upgrade function from the newer version at INSTALL EXTENSION time. Or
invent yet another syntax for upgrading.

And. Wait. That's it.

Oh, you could also try to turn plpgsql, plperl, plpython and their
unstrusted variants into built-in extensions too, and contribs too. It
would be nice if contribs where all CREATEd into template0 and template1
and you only had to INSTALL EXTENSION hstore; for enjoying it. That'd be
a Tom's easy evening I guess :)

Anyone having the hours and skill required to do it? It's great fun,
rewarding, everybody and his neighbour *want* it to be done, and I'll be
as available as possible to answer mails, be there on IRC, and do the
necessary political work if there's still some more to be done.

Consider it as a gift I'm giving you: I'm refusing easily earned
reputation by allowing you to code that for me ;)

Regards,
--
dim

PS: that ought to do it.

On Thu, 2010-01-07 at 13:22 -0800, Josh Berkus wrote:

Dave,

What I'm getting from your e-mail, Dave, is "If it doesn't solve all
problems for everyone in the world from Day 1, it's not worth doing."

I doubt that is Dave's intent because then we might as well stop work on
PostgreSQL too.

David's proposal is designed to be something which he can get done *this
year*, possibly before 8.5 is released, and be built on later. It'll be
useful to a substantial number of our users, and will be an improvement
on what we have now.

I say if Wheeler wants to do it, he should do it and stop quibbling with
the rudiments of the Org opinion. Guess how many people have opinions?

Buildfarm succeeded because someone stepped up, evaluated, took a little
feedback and ran with it. He didn't screw around waiting for everyone to
be happy.

So +1 on Wheeler's idea.

Joshua D. Drake

--Josh Berkus

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.

Building them is no problem - authors can easily use EC2 for which we
have an AMI pre-configured for next to no cost, can build on their own
platform, on a community provided system, or get a friend to do it.

So any module author, in order to submit any module, would be required
to build binaries for 8-12 platforms covering up to 5 PostgreSQL
versions (i.e. 30-70 different binaries)? At their own cost? Seems
like a good way to not get any contributions at all.

For that matter, Andrew just pointed out to me (corrected me, actually)
on IRC that if a Windows user has MSVC or Mingw installed, it should be
no problem supporting them.

So what you're asking has nothing to do with Windows users, but is a
more general "we want support for users who don't have a compiler
installed". That's a different problem -- and one which the One-click
installer or Stackbuilder should probably solve rather than PGAN.

No. The essence is, 'If you're going to do it in a way that will never
work for maybe 50% or more of PostgreSQL installations, then you have
fundamental design issues to overcome'.

Again, that's the wrong attitude. You're saying "If it doesn't work for
100% of Windows users from Day 1, it won't ever work for them." By that
logic, we should have held back version 7.4 until the windows port was
done, dammit! And we shouldn't have released until it worked with
Visual C++. Even if it meant releasing in 2007. And we shouldn't have
released PITR until it supported HS. And we shouldn't be releasing 8.5
without Win64 support.

The reason I'm harping on this is this list has a real tendency to
reject simple solutions which allow room for growth in favor of
overcomplicated world-spanning specifications which will never be
implemented. Despite the fact that we only have some notable features
because we took the simple approach: partitioning, PITR, the Buildfarm,
CommitFests. And that features which there is no obvious way to
implement in small steps incrementally (Windows Port, HS, HOT) are huge
development problems for us.

This list *also* has a real tendency to have an incredible negative
attitude, which *you* are currently expressing. The constructive way
for you to approach this would have been to say "I think that the
general idea has merit, but that putting off Windows support is a
mistake. What about supporting binary distribution at the outset? And
coding the client in C?" Instead, you said "this doesn't solve problems
A, B, and C, so it's stupid."

Building a simple solution which doesn't initially cover all bases but
can be steadily improved is a far superior strategy to trying to spec
The Perfect Solution before even starting work. And if we want to keep
recruiting new contributors, criticism needs to be more constructive.

--Josh Berkus

On Jan 7, 2010, at 1:59 PM, Joshua D. Drake wrote:

So +1 on Wheeler's idea.

Thanks!

David

On tor, 2010-01-07 at 12:07 -0800, David E. Wheeler wrote:

I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL extensions. I've tried to closely follow the [CPAN philosophy][] to come up with a plan that requires a minimum-work implementation that builds on the existing PostgreSQL tools and the examples of the [CPAN][] and [JSAN][]. My hope is that it's full of [JFDI][]! I would be very grateful for feedback and suggestions.

Sounds good.

You might want to clarify in your prose what an "extension" is. I
suspect I know what you mean, but perhaps not everyone does.

On Jan 7, 2010, at 2:11 PM, Peter Eisentraut wrote:

You might want to clarify in your prose what an "extension" is. I
suspect I know what you mean, but perhaps not everyone does.

Good suggestion, thanks. How about this in the FAQ?

* WTF is an "extension"?

An extension is a piece of software that adds functionality to PostgreSQL itself. Examples are data types (CITEXT, PERIOD), utilities (newsysviews, pgTAP), and procedural languages (PL/Ruby, PL/R), among others. An extension is *not* a piece of software designed to run on top of PostgreSQL (Bricolage, Drupal).

Best,

David

"David E. Wheeler" <david@kineticode.com> writes:

On Jan 7, 2010, at 2:11 PM, Peter Eisentraut wrote:

You might want to clarify in your prose what an "extension" is. I
suspect I know what you mean, but perhaps not everyone does.

Good suggestion, thanks. How about this in the FAQ?

* WTF is an "extension"?

An extension is a piece of software that adds functionality to
PostgreSQL itself. Examples are data types (CITEXT, PERIOD), utilities
(newsysviews, pgTAP), and procedural languages (PL/Ruby, PL/R), among
others. An extension is *not* a piece of software designed to run on
top of PostgreSQL (Bricolage, Drupal).

Maybe with a link to:
http://www.postgresql.org/docs/8.4/static/extend.html

In the sections that follow, we will discuss how you can extend the
PostgreSQL SQL query language by adding:

- functions (starting in Section 34.3)
- aggregates (starting in Section 34.10)
- data types (starting in Section 34.11)
- operators (starting in Section 34.12)
- operator classes for indexes (starting in Section 34.14)

The PostgreSQL server can moreover incorporate user-written code into
itself through dynamic loading. That is, the user can specify an
object code file (e.g., a shared library) that implements a new type
or function, and PostgreSQL will load it as required. Code written in
SQL is even more trivial to add to the server. This ability to modify
its operation "on the fly" makes PostgreSQL uniquely suited for rapid
prototyping of new applications and storage structures.

Regards,
--
dim

On Jan 7, 2010, at 2:23 PM, Dimitri Fontaine wrote:

Maybe with a link to:
http://www.postgresql.org/docs/8.4/static/extend.html

Good call, thanks.

David

Dimitri Fontaine <dfontaine@hi-media.com> writes:

e.g. pg_execute_commands_from_file('path/ to/file.sql'). It would not

[...]

Then you need to add a catalog for holding the extensions metadata, like

[...]

Now you can hack a CREATE EXTENSION command to fill-in the catalog, and
the commands INSTALL EXTENSION and DROP EXTENSION to execute the given
files. You have to invent a trick to be able to assign any SQL object
created while executing the install file a dependency entry targeting
the extension's catalog oid. As this is all done in a single given
backend, my guess is that a static variable holding the oid would be
enough, but you still have to touch all object creation code path.

Now that you have dependency information tracked, don't forget to add
pg_dump support by skipping any objects installed as part of an
extension and only issuing INSTALL EXTENSION foo; instead.

Then let pg_restore run this and complain loudly when the needed
extension entry does not exists yet, you have to CREATE and INSTALL the
extension on the new database before getting to restore your dump.

You do *not* have to care about schema in any way *BUT* to prepend the
search_path with pg_extension just before executing the install
file. It's a new schema to provide in template databases, so that
extensions default to creating their objects there. This new schema
should be installed just before pg_catalog in the search_path in places
that search for objects from their non qualified name. Full stop on this
topic.

Oh and special bonus if CREATE EXTENSION, given a newer version of an
already installed extension, will register things so as to run the
upgrade function from the newer version at INSTALL EXTENSION time. Or
invent yet another syntax for upgrading.

And. Wait. That's it.

Oh, you could also try to turn plpgsql, plperl, plpython and their
unstrusted variants into built-in extensions too, and contribs too. It
would be nice if contribs where all CREATEd into template0 and template1
and you only had to INSTALL EXTENSION hstore; for enjoying it. That'd be
a Tom's easy evening I guess :)

Anyone having the hours and skill required to do it? It's great fun,
rewarding, everybody and his neighbour *want* it to be done, and I'll be
as available as possible to answer mails, be there on IRC, and do the
necessary political work if there's still some more to be done.

Consider it as a gift I'm giving you: I'm refusing easily earned
reputation by allowing you to code that for me ;)

Regards,
--
dim

PS: that ought to do it.

Hey, there's about a week left. :)
--
dim

On Thu, Jan 07, 2010 at 12:07:19PM -0800, David Wheeler wrote:

Hackers,

I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL
extensions. I've tried to closely follow the [CPAN philosophy][] to
come up with a plan that requires a minimum-work implementation that
builds on the existing PostgreSQL tools and the examples of the
[CPAN][] and [JSAN][]. My hope is that it's full of [JFDI][]! I
would be very grateful for feedback and suggestions.

+1 for a modest PGAN to start. :)

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

* Josh Berkus (josh@agliodbs.com) wrote:

What I'm getting from your e-mail, Dave, is "If it doesn't solve all
problems for everyone in the world from Day 1, it's not worth doing."
It's my experience that the way to get OSS software that works is to
build a little bit at a time, each delivery of which is useful to some
people and solves some problems. Projects which attempt to paint the
whole world never get anywhere.

+1 from me. I was just discussing this with some other folks at my
company and had to make the point that if all you do is show the CEO a
big fat $ figure, he's gonna say no. If you actually want to make it
happen, you have to show a progression to get there from where we are
today, with the incremental costs required along the way and the
functionality that you get for that.

David's proposal is designed to be something which he can get done *this
year*, possibly before 8.5 is released, and be built on later. It'll be
useful to a substantial number of our users, and will be an improvement
on what we have now.

Sounds excellent to me.

Thanks,

Stephen