Want to add to contrib.... xmldbx

[removing -patches since no patch was attached]

Mark Woodward wrote:

I have a fairly simple extension I want to add to contrib. It is an XML
parser that is designed to work with a specific dialect.

I have a PHP extension called xmldbx, it allows the PHP system to
serialize its web session data to an XML stream. (or just serialize
variables) PHP's normal serializer is a non-standard home grown format
that it impossile to read. The xmldbx format may not be too much easier,
but I have a format document for it. I also have a PostgreSQL extension
that can take serialized data and use it in a query, like:

select xmldbx('data.userdata.id', sessions.data);

If the PHP variable has $userdata['id'] set to some varible in its session
data, it will be returned.

This allows a lot of flexability and a tight integration between
PostgreSQL and PHP.

This sounds highly specialised, and probably more appropriate for a
pgfoundry project.

In any case, surely the whole point about XML is that you shouldn't need
to contruct custom parsers. Should we include a specialised parser for
evey XML dialect someone might want to store in the database?

cheers

andrew

On Sun, Jan 29, 2006 at 02:04:47PM -0500, Mark Woodward wrote:

[removing -patches since no patch was attached] This sounds highly
specialised, and probably more appropriate for a pgfoundry
project.

XML is not really much more than a language, it says virtually
nothing about content. Content requires custom parsers.

<aol>I also think this would make a great pgfoundry project :)</aol>

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 415 235 3778

Remember to vote!

[removing -patches since no patch was attached]
This sounds highly specialised, and probably more appropriate for a
pgfoundry project.

In any case, surely the whole point about XML is that you shouldn't need
to contruct custom parsers. Should we include a specialised parser for
evey XML dialect someone might want to store in the database?

XML is not really much more than a language, it says virtually nothing
about content. Content requires custom parsers.

While I understand the notion that we don't want to have a custom parser
for every XML data spec, I did commit the xmldbx extension into the PHP
extensions.

MySQL has great street cred because it is very well integrated with PHP.
This extension may appeal to PHP users and make it more enticing to
PostgreSQL instead.

David Fetter <david@fetter.org> writes:

<aol>I also think this would make a great pgfoundry project :)</aol>

Yeah ... unless there's some reason that it needs to be tied to PG
server releases, it's better to put it on pgfoundry where you can
have your own release cycle.

regards, tom lane

Mark Woodward wrote:

XML is not really much more than a language, it says virtually nothing
about content. Content requires custom parsers.

Really? Strange I've been dealing with it all this time without having
to contruct a parser. What you do need is to provide event handlers to a
stream parser such as SAX, or a use an API such as DOM to insert/extract
data to/from the XML.

While I understand the notion that we don't want to have a custom parser
for every XML data spec, I did commit the xmldbx extension into the PHP
extensions.

MySQL has great street cred because it is very well integrated with PHP.
This extension may appeal to PHP users and make it more enticing to
PostgreSQL instead.

Postgres generally seems to favor extensibility over integration, and I
generally agree with that approach.

Before we even consider it I would want to see how much traction your
PHP extension gets.

Also, what are its dependencies? If it's dependent on PHP headers to
build or libraries to run that would be unfortunate - we might need to
invent some sort of configure flag to include/exclude some contrib
modules in that case.

cheers

andrew

On 1/29/06, Mark Woodward <pgsql@mohawksoft.com> wrote:

I generally agree as well, but.....

I think there is always a balance between "out of the box" vs
"extensibility." I think integration and extensibility is fantastic for
addaptation of your product, but "oobe" (out of box experience) is
important for those you want to target.

Unlike MySQL, PostgreSQL does not target one audience (i.e. the "low-end").
PostgreSQL targets various groups (scientific, enterprise, hobby, OLTP, ...)
which means that providing a nice OOBE for each of these targets would bloat
the main distribution. No one feels that your project isn't a good one, we
just suggest that moving it to a pgfoundy project would be a better idea.

By all practical measure PostgreSQL is miles ahead of MySQL, but MySQL

wins because it is the defacto PHP database. PostgreSQL does not target
PHP in any real sense, I am proposing adding this extension to change
that.

In most PHP applications I've seen, MySQL wins only because it is the
developer's default database. Likewise, most PHP/MySQL-only applications
are generally poorly designed and developed. To this day, I know of no
specific features in MySQL that make it a nicer database for PHP.

Having a PHP serializer that hooks up to the database in a usable way,

IMHO, makes a strong link between the two.

I agree that it's a nice project, but how many people use PostgreSQL with
languages other than PHP? A language-specific extension would, IMHO, need
to have a real good reason to be included in the main distribution.

This is the classic chicken and the egg thing that kills a potentially

great idea.

Unfortunately, this can be said for everything. However, in the end this
thinking does tend to kill more bad ideas than good ones.

Step back and ask yourself "is it something you see as valuable." If you

answer no, then there is no point in dicussing it anymore. If you answer
"yes," then consider the PHP admin who wants to be able to accomplish what
this provides. The PHP guy will be used to MySQL and not know anything
about PostgreSQL, wouldn't making the barrier to entry lower make sense?

Yes, the project is a great idea. I would surely like to see it in a
pgfoundry project. I also wish we also had a better PostgreSQL developer
tools area on the website which would list these types of projects for PHP,
C, C++, .NET, Java, ...

If it is a "good idea" then, making it easier to do makes sense.

If I were you, I'd just create a pgfoundry project which includes the
contrib module and a few examples.

I wrote it so it could be in the contrib with nothing but expat (which

most systems have.)

We've encountered issues like this with readline, crypt, etc. and I know of
several Linux distros which do not include expat. Likewise, I don't recall
ever seeing expat on Solaris or Windows in a non-application-specific
installation.

Mark Woodward wrote:

XML is not really much more than a language, it says virtually nothing
about content. Content requires custom parsers.

Really? Strange I've been dealing with it all this time without having
to contruct a parser. What you do need is to provide event handlers to a
stream parser such as SAX, or a use an API such as DOM to insert/extract
data to/from the XML.

Yes, those are applications that allow you to create a data handler, expat
is basically everything else is a custom parser.

While I understand the notion that we don't want to have a custom parser
for every XML data spec, I did commit the xmldbx extension into the PHP
extensions.

MySQL has great street cred because it is very well integrated with PHP.
This extension may appeal to PHP users and make it more enticing to
PostgreSQL instead.

Postgres generally seems to favor extensibility over integration, and I
generally agree with that approach.

I generally agree as well, but.....

I think there is always a balance between "out of the box" vs
"extensibility." I think integration and extensibility is fantastic for
addaptation of your product, but "oobe" (out of box experience) is
important for those you want to target.

By all practical measure PostgreSQL is miles ahead of MySQL, but MySQL
wins because it is the defacto PHP database. PostgreSQL does not target
PHP in any real sense, I am proposing adding this extension to change
that.

Having a PHP serializer that hooks up to the database in a usable way,
IMHO, makes a strong link between the two.

Before we even consider it I would want to see how much traction your
PHP extension gets.

This is the classic chicken and the egg thing that kills a potentially
great idea.

Step back and ask yourself "is it something you see as valuable." If you
answer no, then there is no point in dicussing it anymore. If you answer
"yes," then consider the PHP admin who wants to be able to accomplish what
this provides. The PHP guy will be used to MySQL and not know anything
about PostgreSQL, wouldn't making the barrier to entry lower make sense?

If it is a "good idea" then, making it easier to do makes sense.

Also, what are its dependencies? If it's dependent on PHP headers to
build or libraries to run that would be unfortunate - we might need to
invent some sort of configure flag to include/exclude some contrib
modules in that case.

I wrote it so it could be in the contrib with nothing but expat (which
most systems have.)

David Fetter <david@fetter.org> writes:

<aol>I also think this would make a great pgfoundry project :)</aol>

Yeah ... unless there's some reason that it needs to be tied to PG
server releases, it's better to put it on pgfoundry where you can
have your own release cycle.

I don't need pfoundry, per se' but I was hoping that it could be part of
the core distribution.

My personal feelings are these: I use PHP a lot and I use PostgreSQL a lot
for what I do. PHP plays favorites, they actively promote MySQL even
though it is a bad database in the database sense.

I would like to see PostgreSQL, at least passivly, include niceties for
PHP users. In quaint terms, "show them you care."

On a side note, PostgreSQL is a little too self centric. It is a great
project that doesn't get the credit it deserves and I think that it is
because the project, as a whole, doesn't try to actively court or support
popular applications.

The pgfountry and formally gborg are reat, but unless you actively promote
them people can't find them. There should e a big huge button and/or link
to pgfountry that shows how much is availale to PostgreSQL.

Mark Woodward wrote:

There should e a big huge button and/or link
to pgfountry that shows how much is availale to PostgreSQL.

While there are links to 'em mentioned on the web site, I agree that
making (particularly) Pgfoundry more prominent would be a good idea.

Mark, do you want to suggest that on -advocacy (since I suspect that's
the place to get it to happen)?

Cheers

(the other) Mark

On Jan 30, 2006, at 12:23 , Andrew Dunstan wrote:

A nicer idea would be something like a utility could we ship that will
download, build and install module foo for you.

CPAN modules, Ruby gems, PgFoundry ingots? :)

Michael Glaesemann
grzm myrealbox com

Mark Kirkwood said:

Mark Woodward wrote:

There should e a big huge button and/or link
to pgfountry that shows how much is availale to PostgreSQL.

While there are links to 'em mentioned on the web site, I agree that
making (particularly) Pgfoundry more prominent would be a good idea.

Mark, do you want to suggest that on -advocacy (since I suspect that's
the place to get it to happen)?

A nicer idea would be something like a utility could we ship that will
download, build and install module foo for you. Then we could publish many
many modules on pgfoundry, their authors could look after them, and
installing them would be trivial. pgxs should make such a thing a lot
simpler in many cases.

Of course, building it would be quite a bit of work :-)

cheers

andrew

On Mon, Jan 30, 2006 at 12:20:25PM +0900, Michael Glaesemann wrote:

On Jan 30, 2006, at 12:23 , Andrew Dunstan wrote:

A nicer idea would be something like a utility could we ship that will
download, build and install module foo for you.

CPAN modules, Ruby gems, PgFoundry ingots? :)

Tusks? (Extensions of the elephant.)

--
Michael Fuhr

On Sunday 29 January 2006 22:23, Andrew Dunstan wrote:

Mark Kirkwood said:

Mark Woodward wrote:

There should e a big huge button and/or link
to pgfountry that shows how much is availale to PostgreSQL.

While there are links to 'em mentioned on the web site, I agree that
making (particularly) Pgfoundry more prominent would be a good idea.

Mark, do you want to suggest that on -advocacy (since I suspect that's
the place to get it to happen)?

I hate to repeat this sad story, but we're stalling due to the need for server
upgrades on the foundry to make it more robust. Eventually it will get more
play I imagine.

A nicer idea would be something like a utility could we ship that will
download, build and install module foo for you. Then we could publish many
many modules on pgfoundry, their authors could look after them, and
installing them would be trivial. pgxs should make such a thing a lot
simpler in many cases.

Of course, building it would be quite a bit of work :-)

Actually I don't think it would be all that hard. You just need to have each
project produce an xml file with bits of package information (name,
dependencies, version info, etc...) which could then be combined with all the
other packages to produce a complete list of available packages. You then
just need a binary installed with postgresql that can grab the latest copy of
the xml list so it can present a list of packages to install. It then
downloads the packages from pgfoundry directly. The biggest issue is probably
getting the various packages to provide a similar structure for downloading,
but if you got the base system working I think they would be willing to
comply.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Andrew,

A nicer idea would be something like a utility could we ship that
will
download, build and install module foo for you. Then we could publish
many
many modules on pgfoundry, their authors could look after them, and
installing them would be trivial. pgxs should make such a thing a lot
simpler in many cases.

Of course, building it would be quite a bit of work :-)

Yeah, just ask the Perl folks. I believe that CPAN took about 4 years
to get working.

--Josh

Robert Treat wrote:

On Sunday 29 January 2006 22:23, Andrew Dunstan wrote:

Mark Kirkwood said:
...
A nicer idea would be something like a utility could we ship that will
download, build and install module foo for you. Then we could publish many
many modules on pgfoundry, their authors could look after them, and
installing them would be trivial. pgxs should make such a thing a lot
simpler in many cases.

Of course, building it would be quite a bit of work :-)

Actually I don't think it would be all that hard. You just need to have each
project produce an xml file with bits of package information (name,
dependencies, version info, etc...) which could then be combined with all the
other packages to produce a complete list of available packages.

While I'm all for the idea, I don't think the effort should be underestimated. At least it
must be *very* well scoped. Chances are, it becomes extremely huge and complex task. Here
are some thoughts that might be worth considering:

The version-info and dependencies tend to become quite complex very fast, especially if you
have an arbitrary depth in component dependencies. You need to define how "soft" your
versioned dependencies are for instance, i.e. is a dependency to 1.0.4 of some component
automatically supplanted when a new bug fix (1.0.5) is published? If not, can I still get
the source for 1.0.4 should I require it? Will there be a source repository where all old
bundles are found? How is that repository maintained and structured? The meta-data that
describes versions of a component and the dependencies that each version have (they may
vary), where does that live? What happens if, when you resolve the dependencies for a
certain configuration, end up with a graph where you have two versions of the same component?

You then
just need a binary installed with postgresql that can grab the latest copy of
the xml list so it can present a list of packages to install. It then
downloads the packages from pgfoundry directly.

You have a binary so I guess that installing other packages means installing other binaries?
Are they presumed to be found in a binary form at PgFoundry or must they be compiled? If
it's the former, then maintaining binaries is a huge undertaking. Matching binary
dependencies can be a really complex task, even if the platform is one and the same. If it's
the latter, you impose a development environment on the end user. In the windows world,
thats' probably equal to a Msys/MinGW installation (shrug).

Some packages will perhaps not require compilation but must attach to some other
prerequisite software that must be installed on your machine (a specific version of Perl or
Java VM for instance). How would the modules express such dependencies? Perhaps they can be
fulfilled in a multitude of ways? To cope with that, you must introduce virtual components
(interfaces with multiple implementations).

Are you thinking a generic package-install program that will function on all platforms or do
you suggest something that platform specific installers can hook into? For instance, how
does the Windows installer fit in?

The biggest issue is probably
getting the various packages to provide a similar structure for downloading,
but if you got the base system working I think they would be willing to
comply.

Some packages have dependencies to packages that already provide such a structure (CPAN,
Ruby, Maven, to name a few). A packaging tool that make things easy to install must be able
to cope with that too, which makes things even worse.

Kind regards,
Thomas Hallgren

On Mon, Jan 30, 2006 at 10:25:39AM +0100, Thomas Hallgren wrote:

Actually I don't think it would be all that hard. You just need to have
each project produce an xml file with bits of package information (name,
dependencies, version info, etc...) which could then be combined with all
the other packages to produce a complete list of available packages.

While I'm all for the idea, I don't think the effort should be
underestimated. At least it must be *very* well scoped. Chances are, it
becomes extremely huge and complex task. Here are some thoughts that might
be worth considering:

<snip>

To be honest, I think XML is way overkill. Simply provide a makefile
that has the targets install-check, build and install and maybe also
check. Provide a standard way for people to download projects.

CPAN is a nice example, but really it's mostly a frontend to makefiles.

IMHO, stuff on PgFoundry it not going to become popular because we put
links there. It's going to become popular if/when other distributors
can write things like:

for i in <list of projects> ; do
download package
unpack
make install-check (check if dependacies are good)
make build
make install
build package from installed stuff
done

If the makefiles support DESTDIR and a few other such variables,
something like Debian could make a postgresql-goodies. Currently Debian
provides contrib because it's got a standard method of compiling. A
good test is just unpacking the project in the contrib directory of the
postgresql source and running make. If it produces something that
works, you've got the problem licked.

Similarly for RPMs, if a standard top-level spec file can make a
working package, it's going to be easier for other people to
incorporate.

You then
just need a binary installed with postgresql that can grab the latest copy
of the xml list so it can present a list of packages to install. It then
downloads the packages from pgfoundry directly.

I suppose the only thing that really needs to happen is some kind of
index that can be downloaded so people can find stuff. And so an
automated program can actually download the right file. I think
worrying about dependancies at this stage is overkill. Let get things
to the stage where people can say:

$ make install-check
*** Sorry, foomatic 1.07 must be installed

And then we can worry about automatically resolving them.

Some packages have dependencies to packages that already provide such a
structure (CPAN, Ruby, Maven, to name a few). A packaging tool that make
things easy to install must be able to cope with that too, which makes
things even worse.

I don't think that's a real issue. For example, I use Debian. If
something on PgFoundry has been packaged as a Debian package, I'm ten
times more likely to install it than otherwise. What we should be
aiming for is making stuff easy enough to install so that someone in an
afternoon can download 10 projects and create 10 Debian packages, 10
Redhat packages or 10 MSI installer packages.

This is a much easier task for us because only have to provide the
mechanism but not all the handholding. It also means the end result is
something that integrates with the users system better because the
packager can tweak it for the environment, and the author doesn't need
to care.

Indeed, most of the popular pgfoundry projects have already been
packaged. Which was first, the popularity or the packaging?

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Josh Berkus wrote:

Andrew,

A nicer idea would be something like a utility could we ship that
will
download, build and install module foo for you. Then we could publish
many
many modules on pgfoundry, their authors could look after them, and
installing them would be trivial. pgxs should make such a thing a lot
simpler in many cases.

Of course, building it would be quite a bit of work :-)

Yeah, just ask the Perl folks. I believe that CPAN took about 4 years
to get working.

They were kinda blazing a trail.

I don't think Ruby Gems took anything like that long to flesh out.

I agree with most of what Martijn said elsewhere. We shouldn't try to
overengineer something like this.

cheers

andrew

Michael Fuhr wrote:

On Mon, Jan 30, 2006 at 12:20:25PM +0900, Michael Glaesemann wrote:

On Jan 30, 2006, at 12:23 , Andrew Dunstan wrote:

A nicer idea would be something like a utility could we ship that will
download, build and install module foo for you.

CPAN modules, Ruby gems, PgFoundry ingots? :)

Tusks? (Extensions of the elephant.)

Trunks?

cheers

andrew

Andrew Dunstan wrote:

Michael Fuhr wrote:

On Mon, Jan 30, 2006 at 12:20:25PM +0900, Michael Glaesemann wrote:

On Jan 30, 2006, at 12:23 , Andrew Dunstan wrote:

A nicer idea would be something like a utility could we ship that will
download, build and install module foo for you.

CPAN modules, Ruby gems, PgFoundry ingots? :)

Tusks? (Extensions of the elephant.)

Trunks?

Dung?

On Mon, 2006-01-30 at 08:25, Andrew Dunstan wrote:

Josh Berkus wrote:

Andrew,

A nicer idea would be something like a utility could we ship that
will
download, build and install module foo for you. Then we could publish
many
many modules on pgfoundry, their authors could look after them, and
installing them would be trivial. pgxs should make such a thing a lot
simpler in many cases.

Of course, building it would be quite a bit of work :-)

Yeah, just ask the Perl folks. I believe that CPAN took about 4 years
to get working.

They were kinda blazing a trail.

I don't think Ruby Gems took anything like that long to flesh out.

probably cause they were using ruby instead of perl! ;-)

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Mon, 2006-01-30 at 09:01, Christopher Kings-Lynne wrote:

Andrew Dunstan wrote:

Michael Fuhr wrote:

On Mon, Jan 30, 2006 at 12:20:25PM +0900, Michael Glaesemann wrote:

On Jan 30, 2006, at 12:23 , Andrew Dunstan wrote:

A nicer idea would be something like a utility could we ship that will
download, build and install module foo for you.

CPAN modules, Ruby gems, PgFoundry ingots? :)

Tusks? (Extensions of the elephant.)

Trunks?

Dung?

gives a whole new meaning to the term "package delivery"

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On 30 Jan 2006 11:35:13 -0500
Robert Treat <xzilla@users.sourceforge.net> wrote:

CPAN modules, Ruby gems, PgFoundry ingots? :)

Tusks? (Extensions of the elephant.)

Trunks?

Dung?

gives a whole new meaning to the term "package delivery"

What about calling it "Peanuts" since I hear elephants like those?

---------------------------------
Frank Wiles <frank@wiles.org>
http://www.wiles.org
---------------------------------

On Mon, Jan 30, 2006 at 10:01:58PM +0800, Christopher Kings-Lynne wrote:

Andrew Dunstan wrote:

Michael Fuhr wrote:

On Mon, Jan 30, 2006 at 12:20:25PM +0900, Michael Glaesemann wrote:

On Jan 30, 2006, at 12:23 , Andrew Dunstan wrote:

A nicer idea would be something like a utility could we ship that will
download, build and install module foo for you.

CPAN modules, Ruby gems, PgFoundry ingots? :)

Tusks? (Extensions of the elephant.)

Trunks?

Dung?

I think it best to stick with the front-end of the elephant... :)
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

On Mon, Jan 30, 2006 at 10:25:39AM +0100, Thomas Hallgren wrote:

Robert Treat wrote:

On Sunday 29 January 2006 22:23, Andrew Dunstan wrote:

Mark Kirkwood said:
...
A nicer idea would be something like a utility could we ship that will
download, build and install module foo for you. Then we could publish many
many modules on pgfoundry, their authors could look after them, and
installing them would be trivial. pgxs should make such a thing a lot
simpler in many cases.

Of course, building it would be quite a bit of work :-)

Actually I don't think it would be all that hard. You just need to have
each project produce an xml file with bits of package information (name,
dependencies, version info, etc...) which could then be combined with all
the other packages to produce a complete list of available packages.

While I'm all for the idea, I don't think the effort should be
underestimated. At least it must be *very* well scoped. Chances are, it
becomes extremely huge and complex task. Here are some thoughts that might
be worth considering:

I agree, but baby steps is probably better than nothing. Also, there are
now a whole slew of different packaging schemes out there, some of which
are specifically meant to be cross-platform. Darwinports comes to mind,
and I know there's another one on sourceforge. If we're going to create
a pgFoundry packaging/ports system we should definately look at those.

Another possibility is to use pgFoundry itself as part of the guts of
this. It would arguably be easier to maintain stuff like dependancy
information in the pgFoundry database than in some other language that
pgFoundry developers are less likely to be familiar with. There would
still need to be a means to check what packages are installed on a
specific machine, but it should be possible for pgFoundry to dynamically
create a sh or batch script that can check what's on a machine and grab
tarballs as needed.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

On Sun, Jan 29, 2006 at 03:15:06PM -0500, Mark Woodward wrote:

Postgres generally seems to favor extensibility over integration, and I
generally agree with that approach.

I generally agree as well, but.....

I think there is always a balance between "out of the box" vs
"extensibility." I think integration and extensibility is fantastic for
addaptation of your product, but "oobe" (out of box experience) is
important for those you want to target.

By all practical measure PostgreSQL is miles ahead of MySQL, but MySQL
wins because it is the defacto PHP database. PostgreSQL does not target
PHP in any real sense, I am proposing adding this extension to change
that.

Rather than try and include everything and the kitchen-sink in the
baseline PostgreSQL, why not create a set of PHP targeted
ports/packages? Maybe even bundle Apache in there so you've got your own
'LAPP' stack? (Though being a FreeBSD guy, I'd rather have 'FAPP'...)
One of the key advantages to this approach is that now you can really
create a package that makes sense to the target audience by doing things
like automatically including PHP as a procedure language.

And of course, there's no reason this has to be limited to just PHP...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

On Mon, 30 Jan 2006, Mark Woodward wrote:

It gets so frustrating sometimes, it isn't so black and white, there are
many levels of gray. The PostgreSQL project is trying so hard to be
neutral, that it is making itself irrelevant.

We are making ourselves irrelevant because we encourage the use of
PgFoundry vs including everything (and the kitchen sink) in our core
distribution?

That's like saying that Perl is makign itself irrelevant since it doesn't
include all of CPAN in their distribution, or PHP cause they don't include
all of the pear stuff, or ...

If an extension is programmed properly, there is no reason why it can't be
external to the core distribution, and the tools are provided to help
ensure that they are programmed properly ... its not like it used to be,
where you *had* to download the source tar ball in order to make use of
the Makefile infrastructure ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

On Mon, 30 Jan 2006, Robert Treat wrote:

On Sunday 29 January 2006 22:23, Andrew Dunstan wrote:

Mark Kirkwood said:

Mark Woodward wrote:

There should e a big huge button and/or link
to pgfountry that shows how much is availale to PostgreSQL.

While there are links to 'em mentioned on the web site, I agree that
making (particularly) Pgfoundry more prominent would be a good idea.

Mark, do you want to suggest that on -advocacy (since I suspect that's
the place to get it to happen)?

I hate to repeat this sad story, but we're stalling due to the need for
server upgrades on the foundry to make it more robust. Eventually it
will get more play I imagine.

'k, I really hate to disappoint ppl, but there hasn't been a problem with
pgfoundry in a fairly long time now ... we are working on migrating it to
its own server, with most of the 'migration document' done, but we are
bringing on new projects, with the EnterpriseDB folks just bringing online
a few OSS tools, on a weekly basis ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

On Sun, Jan 29, 2006 at 03:15:06PM -0500, Mark Woodward wrote:

Postgres generally seems to favor extensibility over integration, and

I

generally agree with that approach.

I generally agree as well, but.....

I think there is always a balance between "out of the box" vs
"extensibility." I think integration and extensibility is fantastic for
addaptation of your product, but "oobe" (out of box experience) is
important for those you want to target.

By all practical measure PostgreSQL is miles ahead of MySQL, but MySQL
wins because it is the defacto PHP database. PostgreSQL does not target
PHP in any real sense, I am proposing adding this extension to change
that.

Rather than try and include everything and the kitchen-sink in the
baseline PostgreSQL, why not create a set of PHP targeted
ports/packages? Maybe even bundle Apache in there so you've got your own
'LAPP' stack? (Though being a FreeBSD guy, I'd rather have 'FAPP'...)
One of the key advantages to this approach is that now you can really
create a package that makes sense to the target audience by doing things
like automatically including PHP as a procedure language.

And of course, there's no reason this has to be limited to just PHP...

It gets so frustrating sometimes, it isn't so black and white, there are
many levels of gray. The PostgreSQL project is trying so hard to be
neutral, that it is making itself irrelevant.

Designing and including features that a large group of users would like to
have makes sense. Regardless of my extension, I'd love to see PostgreSQL
get a little pro-active in positioning itself better.

On Mon, Jan 30, 2006 at 04:35:15PM -0500, Mark Woodward wrote:

It gets so frustrating sometimes, it isn't so black and white, there are
many levels of gray. The PostgreSQL project is trying so hard to be
neutral, that it is making itself irrelevant.

Designing and including features that a large group of users would like to
have makes sense. Regardless of my extension, I'd love to see PostgreSQL
get a little pro-active in positioning itself better.

Firstly, there's a reason why some of the projects were included before
and have since been removed: Including stuff that depends on PHP in
PosstgreSQL causes build dependancy loops. You have to have PHP
installed to compile PostgreSQL and you need to have PostgreSQL
installed to compile PHP. The only way to solve it is to not mix things
like that. Not to mention that your release cycles are then
intertwined, which is the wrong thing for most projects.

I don't understand what you mean by PostgreSQL trying to be neutral.
Postgres focuses on what it's good at, being a database. It's not
really for or against anything. The PostgreSQL team is not interested
in maintaining code that so clearly falls outside of the scope.

Secondly, if there is a "large group of users" who want this, why
doesn't someone do it? Any one of them could take the source, and
produce a bundle (say a PostgresPHP Plus Pack) that has all the
features you think should be in there. If they can demonstrate they can
maintain it, perhaps the postgresql website can host it the same way it
hosts the windows installer packages (they're not part of postgres
either).

Finally, if there are a bunch of things that would make it easier to
use postgres from PHP, I think they should be part of PHP. Ask the
maintainer of the PHP-Postgres module if they would consider including
it there (has anyone asked them?). On a system dependancy level, PHP
lies on top of PostgreSQL so anything that uses both should be part of
PHP or higher.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Secondly, if there is a "large group of users" who want this, why
doesn't someone do it? Any one of them could take the source, and
produce a bundle (say a PostgresPHP Plus Pack) that has all the
features you think should be in there. If they can demonstrate they can
maintain it, perhaps the postgresql website can host it the same way it
hosts the windows installer packages (they're not part of postgres
either).

Actually that has been done, specifically do address this type of issue.
It is called Mammoth PostgreSQL. It can be found here:

http://www.mammothpostgresql.org/

Joshua D. Drake

--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

On Monday 30 January 2006 16:21, Marc G. Fournier wrote:

On Mon, 30 Jan 2006, Robert Treat wrote:

On Sunday 29 January 2006 22:23, Andrew Dunstan wrote:

Mark Kirkwood said:

Mark Woodward wrote:

There should e a big huge button and/or link
to pgfountry that shows how much is availale to PostgreSQL.

While there are links to 'em mentioned on the web site, I agree that
making (particularly) Pgfoundry more prominent would be a good idea.

Mark, do you want to suggest that on -advocacy (since I suspect that's
the place to get it to happen)?

I hate to repeat this sad story, but we're stalling due to the need for
server upgrades on the foundry to make it more robust. Eventually it
will get more play I imagine.

'k, I really hate to disappoint ppl, but there hasn't been a problem with
pgfoundry in a fairly long time now ... we are working on migrating it to
its own server, with most of the 'migration document' done, but we are
bringing on new projects, with the EnterpriseDB folks just bringing online
a few OSS tools, on a weekly basis ...

I understand why your defensive, but in this case it's misguided. The new
pgfoundry server isn't ready to go yet which is why it hasn't been moved to
yet and why gborg hasn't been transferred over yet. People are busy and
there are other issues, but the point still stands that we've yet to hear
anything from the foundry admin team that sounded like a proclamation to tear
the doors off of the thing.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Mon, 30 Jan 2006, Robert Treat wrote:

On Monday 30 January 2006 16:21, Marc G. Fournier wrote:

On Mon, 30 Jan 2006, Robert Treat wrote:

On Sunday 29 January 2006 22:23, Andrew Dunstan wrote:

Mark Kirkwood said:

Mark Woodward wrote:

There should e a big huge button and/or link
to pgfountry that shows how much is availale to PostgreSQL.

While there are links to 'em mentioned on the web site, I agree that
making (particularly) Pgfoundry more prominent would be a good idea.

Mark, do you want to suggest that on -advocacy (since I suspect that's
the place to get it to happen)?

I hate to repeat this sad story, but we're stalling due to the need for
server upgrades on the foundry to make it more robust. Eventually it
will get more play I imagine.

'k, I really hate to disappoint ppl, but there hasn't been a problem with
pgfoundry in a fairly long time now ... we are working on migrating it to
its own server, with most of the 'migration document' done, but we are
bringing on new projects, with the EnterpriseDB folks just bringing online
a few OSS tools, on a weekly basis ...

I understand why your defensive, but in this case it's misguided. The
new pgfoundry server isn't ready to go yet which is why it hasn't been
moved to yet and why gborg hasn't been transferred over yet. People are
busy and there are other issues, but the point still stands that we've
yet to hear anything from the foundry admin team that sounded like a
proclamation to tear the doors off of the thing.

I'm one of the 'foundry admin team', and I can definitely state that we
have been accepting projects as ppl are proposing them ... as to
gborg->pgfoundry, the only thing that has been holding that up is that the
two systems are not compatible at the DB end of things, so moving ppl over
isn't the easiest thing to do ... but, for those that have approached us
asking to be migrated, we've worked at migrating those over manually ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:

I'm one of the 'foundry admin team', and I can definitely state that we
have been accepting projects as ppl are proposing them ... as to
gborg->pgfoundry, the only thing that has been holding that up is that
the two systems are not compatible at the DB end of things, so moving
ppl over isn't the easiest thing to do ... but, for those that have
approached us asking to be migrated, we've worked at migrating those
over manually ...

Speaking of which, is there anything I can do to help migrating PL/Java? I've asked before
but we never managed to agree on what efforts that were needed.

Regards,
Thomas Hallgren

Mark Woodward wrote:

I don't understand what you mean by PostgreSQL trying to be neutral.
Postgres focuses on what it's good at, being a database. It's not
really for or against anything. The PostgreSQL team is not interested
in maintaining code that so clearly falls outside of the scope.

That is more or less what I'm writing about. I wish people wouldn't take
it as an insult or slam, because it isn't. (I keep saying, I think
PostgreSQL is amazing, and I've been using it for about a decade.) The
source code to PostgreSQL implements a SQL database, the PostgreSQL
Project defines a community creating and using this database.

Is the scope "the source code" or is the scope "The Postgresql Project?" I
think it can be said that getting more people using PostgreSQL is within
the scope of "The PostgreSQL Project." As the open source model promises,
we trust that the more people who use PostgreSQL the better off "The
PostgreSQL Project" will be. The better "The PostgreSQL Project" is,
theoretically, the more numerous the resources for the project will
become, makeing the community better able to improve the source code.

The community is an important part of "scope."

There clearly is a difference, but you started this Mark by asking to
bundle your xmldbx with the core distribution (into "contrib") - thus
implying "source code".

Now - there might well be a good argument for an xmldbx package that
users can one-click install. Since I've got dozens of xxx-pgsql packages
available this way on my Ubuntu desktop, I'm guessing you're thinking
more of Windows.

So, if we reword your question: "Is there, or should there be a simple
way to download and install packages/plugins for PostgreSQL via the
installer?" Now you've got "No" and "Yes" as your answers, but that's
got nowt to do with "contrib/".

Of course, there's still the small issue of implementation...
--
Richard Huxton
Archonet Ltd

On Mon, Jan 30, 2006 at 04:35:15PM -0500, Mark Woodward wrote:

It gets so frustrating sometimes, it isn't so black and white, there are
many levels of gray. The PostgreSQL project is trying so hard to be
neutral, that it is making itself irrelevant.

Designing and including features that a large group of users would like
to
have makes sense. Regardless of my extension, I'd love to see PostgreSQL
get a little pro-active in positioning itself better.

Firstly, there's a reason why some of the projects were included before
and have since been removed: Including stuff that depends on PHP in
PosstgreSQL causes build dependancy loops. You have to have PHP
installed to compile PostgreSQL and you need to have PostgreSQL
installed to compile PHP. The only way to solve it is to not mix things
like that. Not to mention that your release cycles are then
intertwined, which is the wrong thing for most projects.

The dependency thing is a HUGE problem in general, the solution to which
is not removing cooperation between packages, but through published and
standardized APIs. Of all the crap that Microsoft gets wrong, they have
the right idea when it comes to standarized APIs. A Windows program
written for Windows 95, 11 years ago, runs perfectly fine on Windows XP.

the libpq is a pretty good example as well, as long as the API stays
standard, everything behind it can move all over the place.

I don't understand what you mean by PostgreSQL trying to be neutral.
Postgres focuses on what it's good at, being a database. It's not
really for or against anything. The PostgreSQL team is not interested
in maintaining code that so clearly falls outside of the scope.

That is more or less what I'm writing about. I wish people wouldn't take
it as an insult or slam, because it isn't. (I keep saying, I think
PostgreSQL is amazing, and I've been using it for about a decade.) The
source code to PostgreSQL implements a SQL database, the PostgreSQL
Project defines a community creating and using this database.

Is the scope "the source code" or is the scope "The Postgresql Project?" I
think it can be said that getting more people using PostgreSQL is within
the scope of "The PostgreSQL Project." As the open source model promises,
we trust that the more people who use PostgreSQL the better off "The
PostgreSQL Project" will be. The better "The PostgreSQL Project" is,
theoretically, the more numerous the resources for the project will
become, makeing the community better able to improve the source code.

The community is an important part of "scope."

Secondly, if there is a "large group of users" who want this, why
doesn't someone do it?

Hello?

Any one of them could take the source, and
produce a bundle (say a PostgresPHP Plus Pack) that has all the
features you think should be in there. If they can demonstrate they can
maintain it, perhaps the postgresql website can host it the same way it
hosts the windows installer packages (they're not part of postgres
either).

There is a difference between having an "after market" part and being
included in the OEM version. This is the IE vs Netscape argument. If
people can download Netscape for free, why was IE pre-installed a problem?
Becuase it is an extra step the user may not want to take or know to take.
If something is there for them from the start, it is easier.

Secondly, building a new community takes years and resources with no
guarentee of success, if there are existing communities with fundimentally
similar goals, it makes more sense to become part of a larger community
than it does to create a new one.

On Mon, 30 Jan 2006, Mark Woodward wrote:

It gets so frustrating sometimes, it isn't so black and white, there are
many levels of gray. The PostgreSQL project is trying so hard to be
neutral, that it is making itself irrelevant.

We are making ourselves irrelevant because we encourage the use of
PgFoundry vs including everything (and the kitchen sink) in our core
distribution?

You know, like CPAN, BSD ports, and other sorts of things, I don't have a
problem with pgfountry, per se', but who but hackers knows what it is?
pgfoundry would be amazing if you called attention to it. I am reminded of
Douglas Adams, "I Eventually found it, in a disused lavatory in a locked
file cabinaet with a sign on it saying, 'beware of the leopod'" or
something like that.

On the home page, pgFoundry, is between "Mailing Lists" and "Techdocs,"
who's going to see it, and who would even know what "pgFoundry" means?
Only the very curious with spare time on their hands. In PostgreSQL's
download page, you do mention a few select projects under the heading
"Other Software"

Squirrelmail puts their "plugins" right next to download.
Drupal puts a "modules" tab right next to the project tab.

That's like saying that Perl is makign itself irrelevant since it doesn't
include all of CPAN in their distribution, or PHP cause they don't include
all of the pear stuff, or ...

CPAN is amazing.

If an extension is programmed properly, there is no reason why it can't be
external to the core distribution, and the tools are provided to help
ensure that they are programmed properly ... its not like it used to be,
where you *had* to download the source tar ball in order to make use of
the Makefile infrastructure ...

Yes, creating an extension has improved quite a bit, pg_config should
handle more of the standards options like --prefix, but it has improved
quite a bit.