Обсуждение: Want to add to contrib.... xmldbx

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.

For more information:
http://www.mohawksoft.org -- (The open source end of mohawk softare :-)

What do you all think?

[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

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

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!

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

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

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

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/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

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 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, 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 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/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

> 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

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

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