SEO

[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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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!

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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.

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


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq