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

Wed, 19 May 2004 09:43:52 -0700
Josh Berkus <josh@agliodbs.com>
Re: Call for 7.5 feature completion
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

Wed, 19 May 2004 13:28:30 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: Call for 7.5 feature completion
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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Wed, 19 May 2004 13:43:55 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Call for 7.5 feature completion
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


Wed, 19 May 2004 20:32:45 +0200
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <postgres@cybertec.at>
Re: Call for 7.5 feature completion
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@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Wed, 19 May 2004 21:36:50 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: Call for 7.5 feature completion
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@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Wed, 19 May 2004 21:39:07 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: Call for 7.5 feature completion
On Wed, 19 May 2004, [ISO-8859-1] Hans-J�rgen Sch�nig 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@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Wed, 19 May 2004 21:48:20 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Core vs non-Core (Was: Re: Call for 7.5 feature completion)
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



Wed, 19 May 2004 21:13:02 -0400 (EDT)
"Andrew Dunstan" <andrew@dunslane.net>
Re: Call for 7.5 feature completion
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



Wed, 19 May 2004 21:25:52 -0400 (EDT)
"Andrew Dunstan" <andrew@dunslane.net>
Re: Call for 7.5 feature completion
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@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Thu, 20 May 2004 00:16:36 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: Call for 7.5 feature completion