Re: Want to add to contrib.... xmldbx
| От | Jonah H. Harris |
|---|---|
| Тема | Re: Want to add to contrib.... xmldbx |
| Дата | |
| Msg-id | 36e682920601291212r45859941v1a49a2693b948465@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Want to add to contrib.... xmldbx ("Mark Woodward" <pgsql@mohawksoft.com>) |
| Список | pgsql-hackers |
On 1/29/06, Mark Woodward <pgsql@mohawksoft.com> wrote:
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.
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.
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.
Unfortunately, this can be said for everything. However, in the end this thinking does tend to kill more bad ideas than good ones.
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 I were you, I'd just create a pgfoundry project which includes the contrib module and a few examples.
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.
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.
В списке pgsql-hackers по дате отправления:
Следующее
От: Euler Taveira de OliveiraДата:
Сообщение: Re: GRANT/REVOKE: Allow column-level privileges