-----Original Message-----
From: "Jonah H. Harris"<jonah.harris@gmail.com>
Sent: 15/04/06 20:06:27
To: "Pgsql Hackers"<pgsql-hackers@postgresql.org>
Subject: [HACKERS] Google SoC--Idea Request


> As such, we need to quickly put together a list of oh, 15-20 midlevel
> project ideas.

There's a couple of listen/notify todos iirc that would be nice to get done - one to allow a message to be sent with the notify, and one to move from a table based design to shared mem/disk.

Regards, Dave

-----Unmodified Original Message-----
Hey everyone,

I know we started a discussion a month or so ago regarding ideas for
SoC projects. However, after reading through the thread, I didn't see
us nail down any actual items.

As such, we need to quickly put together a list of oh, 15-20 midlevel
project ideas. I'm sure we can pull some off the TODO list, but we
should also look at project ideas for porting some of the most used
third-party OSS software to PostgreSQL too (portals, CMS systems,
accounting systems, etc.).

All ideas welcome!

--
Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
732.331.1324

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

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

http://archives.postgresql.org

On Sat, 2006-04-15 at 21:24 +0100, Dave Page wrote:
> one to allow a message to be sent with the notify, and one to move
> from a table based design to shared mem/disk.

Doing the latter is a precondition for implementing the former in a
reasonable way, I believe.

BTW, these two web log entries summarizing Mono and Mozilla's
experiences with SoC might make interesting reading:

http://weblogs.mozillazine.org/gerv/...months_on.html
http://tirania.org/blog/archive/2006/Apr-13.html

> we should also look at project ideas for porting some of the most used
> third-party OSS software to PostgreSQL too (portals, CMS systems,
> accounting systems, etc.).

Given the above, I would be wary of such projects bit-rotting. If the
upstream project hasn't bothered to add PostgreSQL support, there might
be a good reason why: writing truly database-agnostic applications is
not always easy (or even desirable).

-Neil



---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On 4/15/06, Neil Conway <neilc@samurai.com> wrote:
> Doing the latter is a precondition for implementing the former in a
> reasonable way, I believe.


> BTW, these two web log entries summarizing Mono and Mozilla's
> experiences with SoC might make interesting reading:

Thanks for the reading material. I don't think our project is exactly
the same, but it's good information to keep in mind.

> Given the above, I would be wary of such projects bit-rotting. If the
> upstream project hasn't bothered to add PostgreSQL support, there might
> be a good reason why: writing truly database-agnostic applications is
> not always easy (or even desirable).

This isn't always the case. In a lot of cases, the developers just
wanted to take the easy route and used MySQL... they have a lot of
people asking for PostgreSQL support but they don't have the expertise
to add it themselves.

--
Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
732.331.1324

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

On Saturday 15 April 2006 19:25, Jonah H. Harris wrote:
> On 4/15/06, Neil Conway <neilc@samurai.com> wrote:
> > Doing the latter is a precondition for implementing the former in a
> > reasonable way, I believe.
> >
> >
> > BTW, these two web log entries summarizing Mono and Mozilla's
> > experiences with SoC might make interesting reading:
>
> Thanks for the reading material. I don't think our project is exactly
> the same, but it's good information to keep in mind.
>

Agreed. I sent some ideas to Josh, was thinking he might be posting a list
soon. I kept it aimed at a few ideas I have had/seen that need an initial
push to get going but beyond that could be (and likely would be) community
maintained. Example? Extendning the build farm code to test external pl
langs or database drivers or patches other modules. We've talked about it,
and if someone had the time to make the push, I believe this would be
community maintained going forward.

> > Given the above, I would be wary of such projects bit-rotting. If the
> > upstream project hasn't bothered to add PostgreSQL support, there might
> > be a good reason why: writing truly database-agnostic applications is
> > not always easy (or even desirable).
>
> This isn't always the case. In a lot of cases, the developers just
> wanted to take the easy route and used MySQL... they have a lot of
> people asking for PostgreSQL support but they don't have the expertise
> to add it themselves.
>

I think more importantly is that the time needed to do an initial port is
often much greater than it is to maintain a port.

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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match