From: Josh Berkus on
On 1/19/10 9:28 AM, Greg Smith wrote:
> Takahiro Itagaki wrote:
>> The conclusion is splitting existing projects into some 'modules',
>> and getting the modules one by one into core. Voted features are here:
>> http://wiki.postgresql.org/wiki/ClusterFeatures
>>
> This page was a bit messy for someone who didn't attend the meeting to
> follow. I just cleaned it up so that the features are listed in voting
> order, and to have more inter-page links. It's better, but could use
> some more work still.

Yeah, we'll be cleaning it up and fleshing it out more from now until pgCon.

--Josh Berkus

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tatsuo Ishii on
> On 1/19/10 9:28 AM, Greg Smith wrote:
> > Takahiro Itagaki wrote:
> >> The conclusion is splitting existing projects into some 'modules',
> >> and getting the modules one by one into core. Voted features are here:
> >> http://wiki.postgresql.org/wiki/ClusterFeatures

"splitting existing projects into some 'modules', and getting the
modules one by one into core" was not the concluion, actually.

For example, see below from above URL: This means that we expect
PostgreSQL exports it's parser so that existing cluster softwares can
use it. Not opposite direction.

> API into the Parser / Parser as an independent module
>
> * just first step, before going to the catalog
> * statement based replication need to reply certain constructs with CONSTAnT values you provide
> * Figure out which you need to replace... quite difficult
> * but if we have the plan, could do better
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

> > This page was a bit messy for someone who didn't attend the meeting to
> > follow. I just cleaned it up so that the features are listed in voting
> > order, and to have more inter-page links. It's better, but could use
> > some more work still.
>
> Yeah, we'll be cleaning it up and fleshing it out more from now until pgCon.
>
> --Josh Berkus
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Takahiro Itagaki on

Tatsuo Ishii <ishii(a)postgresql.org> wrote:

> "splitting existing projects into some 'modules', and getting the
> modules one by one into core" was not the concluion, actually.
>
> For example, see below from above URL: This means that we expect
> PostgreSQL exports it's parser so that existing cluster softwares can
> use it. Not opposite direction.

I think they says the same practically -- at least have the same impact.

It says postgres need to export the the internal feature *only for* some
of external cluster softwares. So, if you are thinking about exporting
some features from the core, the exported features would better to be
stable enough and shared by several third-party tools.

Regards,
---
Takahiro Itagaki
NTT Open Source Software Center



--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on
Takahiro Itagaki <itagaki.takahiro(a)oss.ntt.co.jp> writes:
> Tatsuo Ishii <ishii(a)postgresql.org> wrote:
>> For example, see below from above URL: This means that we expect
>> PostgreSQL exports it's parser so that existing cluster softwares can
>> use it. Not opposite direction.

> I think they says the same practically -- at least have the same impact.

> It says postgres need to export the the internal feature *only for* some
> of external cluster softwares. So, if you are thinking about exporting
> some features from the core, the exported features would better to be
> stable enough and shared by several third-party tools.

[ raised eyebrow... ]

It's going to be a really, really, *really* hard sell to get us to
export any sort of external API to the parser internals. At least
if by "API" you mean something other than "we will whack this around
to an indefinite degree on no notice, and don't even think about
complaining".

What exactly is the goal that you think such a thing would serve,
anyway? The fragments on the referenced web page don't leave me with
any warm feelings about how well the idea has been thought through.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Takahiro Itagaki on

Tom Lane <tgl(a)sss.pgh.pa.us> wrote:

> It's going to be a really, really, *really* hard sell to get us to
> export any sort of external API to the parser internals. At least
> if by "API" you mean something other than "we will whack this around
> to an indefinite degree on no notice, and don't even think about
> complaining".
>
> What exactly is the goal that you think such a thing would serve,
> anyway? The fragments on the referenced web page don't leave me with
> any warm feelings about how well the idea has been thought through.

Some of items in the referenced web page are just voted results form cluster
projects. At this time, we should read them as "what is needed", but not
"how to do it". They have been not reviewd yet and not well-considered
to be official TODO items.

I知 not sure what pgpool team think about, but I do NOT intend to export the
existing internal functions as-is. As for my personal goal, I think pgpool
should be re-implemented on the layers of SQL/MED FDW or planner/executor hooks.
I'd say the SQL/MED FDW apporach is "one by one into core (from projects)",
and the hook apporach is "external API (from core)".

Regards,
---
Takahiro Itagaki
NTT Open Source Software Center



--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers