Re: Call for 7.5 feature completion

People,

> >So, why tie it into the PostgreSQL source tree? Won't it be popular
> >enough to live on its own, that it has to be distributed as part of the
> >core?

Personally, I find it rather inconsistent to have any PL, other than PL/pgSQL,
as part of the core distribution -- when we are pushing the interfaces, such
as JDBC and libpqxx to seperate modules in pgFoundry. Either we're trying
to lighten up the core, or we're not. But right now there seems to be no
logic in operation.

I do think, though, that we need some system to build RPMs for all the
pgFoundry stuff ...

--
Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus wrote:

>People,
>
>
>
>>>So, why tie it into the PostgreSQL source tree? Won't it be popular
>>>enough to live on its own, that it has to be distributed as part of the
>>>core?
>>>
>>>
>
>Personally, I find it rather inconsistent to have any PL, other than PL/pgSQL,
>as part of the core distribution -- when we are pushing the interfaces, such
>as JDBC and libpqxx to seperate modules in pgFoundry. Either we're trying
>to lighten up the core, or we're not. But right now there seems to be no
>logic in operation.
>
>I do think, though, that we need some system to build RPMs for all the
>pgFoundry stuff ...
>
>
>

Server-side PLs might have quite different requirements from Client
Interfaces. I don't think you can simply extrapolate in this way.

Personally, I hate the idea of having to write stuff like this example
Joe Conway gave the other day from PL/R:

#if (CATALOG_VERSION_NO <= 200211021)
#define PG_VERSION_73_COMPAT
#elif (CATALOG_VERSION_NO <= 200310211)
#define PG_VERSION_74_COMPAT
#else
#define PG_VERSION_75_COMPAT
#endif

and all the consequent mess.

Yuck.

Frankly, although I am a relative newcomer around here, I am not
convinced that "lightening the core" has been a great success, or can be
made to be so. Certainly Peter's comments on the history to date suggest
that a re-evaluation might be in order.

cheers

andrew

Andrew Dunstan wrote:
> Frankly, although I am a relative newcomer around here, I am not
> convinced that "lightening the core" has been a great success, or can be
> made to be so. Certainly Peter's comments on the history to date suggest
> that a re-evaluation might be in order.

Moving stuff out makes their release schedules and community involvement
independent, but from a code activity and ease-of-use perspective, it
has been a general failure, with only a few successes.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Josh Berkus wrote:
> People,
>
>
>>>So, why tie it into the PostgreSQL source tree? Won't it be popular
>>>enough to live on its own, that it has to be distributed as part of the
>>>core?
>
>
> Personally, I find it rather inconsistent to have any PL, other than PL/pgSQL,
> as part of the core distribution -- when we are pushing the interfaces, such
> as JDBC and libpqxx to seperate modules in pgFoundry. Either we're trying
> to lighten up the core, or we're not. But right now there seems to be no
> logic in operation.
>
> I do think, though, that we need some system to build RPMs for all the
> pgFoundry stuff ...
>

As far as this discussion is concerned I personally think that there is
just one way to satisfy everybody.
I we had a "PostgreSQL most wanted" distribution including PL/* as well
as some other modules we could save people compiling PostgreSQL from
source a lot of work.
The core itself would be cleaner (which is the target of moving things
out) and everybody would be happy?
If people think this is a good idea I could compile and maintain this
(source) distribution ...

Best regards,

Hans

--
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/720/10 1234567 or +43/664/233 90 75
www.cybertec.at, www.postgresql.at, kernel.cybertec.at

On Wed, 19 May 2004, Josh Berkus wrote:

> People,
>
> > >So, why tie it into the PostgreSQL source tree? Won't it be popular
> > >enough to live on its own, that it has to be distributed as part of the
> > >core?
>
> Personally, I find it rather inconsistent to have any PL, other than
> PL/pgSQL, as part of the core distribution -- when we are pushing the
> interfaces, such as JDBC and libpqxx to seperate modules in pgFoundry.

Actually, JDBC, libpqxx, ODBC, plPHP, plPerlNG are all really easy to push
over to pgFoundry ... they have very active, and visible, developers
responsible for them ... is anyone out there directing work on pl/pgsql or
pl/TCL? If so, they are easy to move also ...

> Either we're trying to lighten up the core, or we're not. But right now
> there seems to be no logic in operation.

Its easier to *not add* something to core (ie. plPHP/plPerlNG) then it is
to remove something (see JDBC) ...

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

On Wed, 19 May 2004, Andrew Dunstan wrote:

> Personally, I hate the idea of having to write stuff like this example
> Joe Conway gave the other day from PL/R:
>
> #if (CATALOG_VERSION_NO <= 200211021)
> #define PG_VERSION_73_COMPAT
> #elif (CATALOG_VERSION_NO <= 200310211)
> #define PG_VERSION_74_COMPAT
> #else
> #define PG_VERSION_75_COMPAT
> #endif

Why not have seperate branches in CVS for each version? Branch on similar
dates to the core distribution itself?

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

On Wed, 19 May 2004, [ISO-8859-1] Hans-Jrgen Schnig wrote:

> If people think this is a good idea I could compile and maintain this
> (source) distribution ...

I'd love to see something like this ...

One question I have is what would it take to extend teh build system in
core so that it was easier to do this? For instance, for those wishing to
do something like this, what would it take to have it so that you could
'cvs checkout':

pgsql (the core)
pgsql/src/interfaces/jdbc (from pgfoundry)
pgsql/src/interfaces/odbc (from pgfoundry)

I know that pulling in the various source codes isn't a difficult script
to write, but how about adding in the building of the included modules?
Maybe have the optional modules in a pgsql/src/modules directory?

I know its doable ... apache does it ...

... and I've seen other software/projects where configure in the root
calls configure in the modules directory itself, so that's doable ...

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

Marc G. Fournier said:
> On Wed, 19 May 2004, Josh Berkus wrote:
>
>> People,
>>
>> > >So, why tie it into the PostgreSQL source tree? Won't it be
>> > >popular enough to live on its own, that it has to be distributed as
>> > >part of the core?
>>
>> Personally, I find it rather inconsistent to have any PL, other than
>> PL/pgSQL, as part of the core distribution -- when we are pushing the
>> interfaces, such as JDBC and libpqxx to seperate modules in pgFoundry.
>
> Actually, JDBC, libpqxx, ODBC, plPHP, plPerlNG are all really easy to
> push over to pgFoundry ... they have very active, and visible,
> developers responsible for them ... is anyone out there directing work
> on pl/pgsql or pl/TCL? If so, they are easy to move also ...
>
>> Either we're trying to lighten up the core, or we're not. But right
>> now there seems to be no logic in operation.
>
> Its easier to *not add* something to core (ie. plPHP/plPerlNG) then it
> is to remove something (see JDBC) ...
>

plperlng is not "something not in the core". It is a project to improve
something that *is* in the core. That has always been my intention, and it
is clear from his comments that it has always been Joshua Drake's too.

cheers

andrew

Marc G. Fournier said:
> On Wed, 19 May 2004, Andrew Dunstan wrote:
>
>> Personally, I hate the idea of having to write stuff like this example
>> Joe Conway gave the other day from PL/R:
>>
>> #if (CATALOG_VERSION_NO <= 200211021)
>> #define PG_VERSION_73_COMPAT
>> #elif (CATALOG_VERSION_NO <= 200310211)
>> #define PG_VERSION_74_COMPAT
>> #else
>> #define PG_VERSION_75_COMPAT
>> #endif
>
> Why not have seperate branches in CVS for each version? Branch on
> similar dates to the core distribution itself?
>

And thus demolish your argument that it is in the interests of projects to
have independent release dates. And make the task more complex.

All this will do is make life harder. We should be about making it easier.

cheers

andrew

On Wed, 19 May 2004, Andrew Dunstan wrote:

> > Why not have seperate branches in CVS for each version? Branch on
> > similar dates to the core distribution itself?
> >
>
> And thus demolish your argument that it is in the interests of projects to
> have independent release dates. And make the task more complex.

How do you figure that? If you do a 7.4 branch of a project, around the
same time as 7.4 of PostgreSQL, you have code that is specific to that
release that you can apply patches/improvements to. By being a seperate
project, you don't hvae to wait for 7.4.1 to be released in order to
release a new version of the project ... I'm not even say call it a 7.4
branch ... just associate it with it ...

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