Hello everybody,

After Marc Fournier commented, it is time for pgaccess.org to make a
decision.

It is clear the project needs the following tools.

- web site
- mailing list(s)
- cvs
- bug tracking system

It is clear, that there is a small new group with fresh desire to contribute
in a dedicated way.

It is clear, that pgaccess has only one meaning and this is PostgreSQL.

It is clear, that the PostgreSQL core team is very supportive.

It is clear, that pgaccess.org efforts can not result in anything good
without a close collaboration with the PostgreSQL core team.

Now, when we heard many different opinions, the question is - what is the
best decision of organization.

I would make the following summary, please, send your comments -


SUMMARY

1] In terms of infrastructure, a separate web site, mailing list(s) and bug
tracking system will increase the flexibility of the pgaccess team and will
not create additional (and not very useful) burden for the PostgreSQL core
team. The pgaccess is a tool - it is not an integral part of PostgreSQL and
does not need day-to-day sharing. In the beginning it will be developed
rather for the stable, than for the future versions of PostgreSQL.

2] It is clear that there must be one master copy of the CVS. The
possibilities are two - this copy is kept with PostgreSQL or this copy is
kept with pgaccess.org

If the PostgreSQL core team can provide a CVS repository with similar
flexibility to that it would have being based on the pgaccess.org server - I
would vote for a PostgreSQL hosted CVS. This will be the naval cord between
the two projects.

3] Still - the only thing that is not clear to me is - who is going to
collect all patches and make one whole form them. As long as each of us
works on a different thing - this should not be a big problem, but still -
needs to be one person.

Iavor

--
www.pgaccess.org


Fri, 10 May 2002 10:58:28 +0200
"Iavor Raytchev" <iavor.raytchev@verysmall.org>
internal voting
On Fri, 10 May 2002 10:58:28 +0200
"Iavor Raytchev" <iavor.raytchev@verysmall.org> wrote:

> Hello everybody,
> 
> After Marc Fournier commented, it is time for pgaccess.org to make a
> decision.
> 
> It is clear the project needs the following tools.
> 
> - web site
> - mailing list(s)
> - cvs
> - bug tracking system
> 
> It is clear, that there is a small new group with fresh desire to
> contribute in a dedicated way.
> 
> It is clear, that pgaccess has only one meaning and this is PostgreSQL.
> 
> It is clear, that the PostgreSQL core team is very supportive.
> 
> It is clear, that pgaccess.org efforts can not result in anything good
> without a close collaboration with the PostgreSQL core team.
> 
> Now, when we heard many different opinions, the question is - what is
> the best decision of organization.
> 
> I would make the following summary, please, send your comments -
> 
> 
> SUMMARY
> 
> 1] In terms of infrastructure, a separate web site, mailing list(s) and
> bug tracking system will increase the flexibility of the pgaccess team
> and will not create additional (and not very useful) burden for the
> PostgreSQL core team. The pgaccess is a tool - it is not an integral
> part of PostgreSQL and does not need day-to-day sharing. In the
> beginning it will be developed rather for the stable, than for the
> future versions of PostgreSQL.
> 
> 2] It is clear that there must be one master copy of the CVS. The
> possibilities are two - this copy is kept with PostgreSQL or this copy
> is kept with pgaccess.org
> 
> If the PostgreSQL core team can provide a CVS repository with similar
> flexibility to that it would have being based on the pgaccess.org server
> - I would vote for a PostgreSQL hosted CVS. This will be the naval cord
> between the two projects.
> 
> 3] Still - the only thing that is not clear to me is - who is going to
> collect all patches and make one whole form them. As long as each of us
> works on a different thing - this should not be a big problem, but still
> - needs to be one person.
> 

This looks all good to me, except I have one question: How will pgaccess
be distributed? Personally, I like the idea that PG comes with pgaccess in
the distribution, so I would hate to see that go away. Even though there
are people that don't use pgaccess, it is always nice to have a default 
tool that comes with PG (yes, I know there is psql).

    --brett

p.s. I am willing to help out as well...



Fri, 10 May 2002 04:25:52 -0700
Brett Schwarz <brett_schwarz@yahoo.com>
Re: internal voting
Iavor Raytchev writes:

> 3] Still - the only thing that is not clear to me is - who is going to
> collect all patches and make one whole form them. As long as each of us
> works on a different thing - this should not be a big problem, but still -
> needs to be one person.

As far as I'm concerned, there is no need to change anything.  If someone
has patches for pgaccess, send them to -patches and they will be applied.
When a new release of PostgreSQL happens, a new pgaccess will be
distributed.  Simple enough.

If and when patches for pgaccess appear in significant numbers and for
some reason, which I cannot imagine, this procedure doesn't end up being
practical, we can consider the alternatives.  But before you spend a lot
of time building a new infrastructure, let's see some code.

-- 
Peter Eisentraut   peter_e@gmx.net


Fri, 10 May 2002 23:24:40 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: internal voting
> If and when patches for pgaccess appear in significant numbers and for
> some reason, which I cannot imagine, this procedure doesn't end up being
> practical, we can consider the alternatives.  But before you spend a lot
> of time building a new infrastructure, let's see some code.
>
> --
> Peter Eisentraut   peter_e@gmx.net

We are working on it, because we have some code.

Don't you believe us, or do you think we have a lot of free time to waste?

We - Chris, Bartus, Boyan and myself, have enough patches we want to merge.
And we do not feel like asking for permisson to do it. We sent them to Teo
and we were asked by Teo to meet and see what we can do with our patches.
And we were nice enough to tell the world about this.

I do not feel neither like 'asking for permisson', nor like 'proving'
anything. If somebody wants to help - is welcome.

I think the discussion is over.

We have some work to do.

Iavor


Fri, 10 May 2002 23:40:28 +0200
"Iavor Raytchev" <iavor.raytchev@verysmall.org>
pgaccess - the discussion is over
On Fri, May 10, 2002 at 11:24:40PM +0200, Peter Eisentraut wrote:
> Iavor Raytchev writes:
> 
> > 3] Still - the only thing that is not clear to me is - who is going to
> > collect all patches and make one whole form them. As long as each of us
> > works on a different thing - this should not be a big problem, but still -
> > needs to be one person.
> 
> As far as I'm concerned, there is no need to change anything.  If someone
> has patches for pgaccess, send them to -patches and they will be applied.
> When a new release of PostgreSQL happens, a new pgaccess will be
> distributed.  Simple enough.
> 
> If and when patches for pgaccess appear in significant numbers and for
> some reason, which I cannot imagine, this procedure doesn't end up being
> practical, we can consider the alternatives.  But before you spend a lot
> of time building a new infrastructure, let's see some code.

All very practical, execpt for one point: the people being pulled togther
for this _have_ code, with nowhere to put it: they've been developing
new features for pgaccess, on top of the stable pgsql. Tracking CVS
tip means that the current version of pgaccess there is either broken
by underlying pgsql changes (I think that is currently true with Tom's
schema work) or does not work with the current stable version og pgsql.

While it would be nice to have one pgaccess that can work with any pgsql
backend, that's not currently the case. One solution would be to work
on the release branch, but that's discouraged - bug fixes only.

Ross

Fri, 10 May 2002 16:42:05 -0500
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: internal voting
...
> While it would be nice to have one pgaccess that can work with any pgsql
> backend, that's not currently the case. One solution would be to work
> on the release branch, but that's discouraged - bug fixes only.

Actually, CVS can support this just fine (I'll mention how below) but
afaict the discussion is moot because Iavor has declared that his group
prefers to take another path for now.

                   - Thomas

The solution could be to make a branch off of the stable branch to
support the pgaccess work. When folks are ready to merge down and
develop for 7.3, then they can do that using the "-j" option, jumping
straight from their development branch down to the main trunk (hence
never corrupting the stable branch), and then develop from there.

Fri, 10 May 2002 15:06:47 -0700
Thomas Lockhart <lockhart@fourpalms.org>
Re: internal voting
> Actually, CVS can support this just fine (I'll mention how below) but
> afaict the discussion is moot because Iavor has declared that his group
> prefers to take another path for now.
>
>                    - Thomas

It is not 'my' group! I just happened to ask somebody in my company to patch
something and then I send the code to Teo. And Teo asked Chris, Bartus and
myself to bring our patches together. And I though of making this public.

The discussion, however, went far beyond my intention.

If somebody feels like managing this - I am off. I do not intend to moderate
the future of an open source project in such a heavy climate. Especialy of a
project I am not the author, not even a contributor - I am a pure manager.

If nobody feels like managing this - let's give it a little bit of life and
move it a bit forwards - and then talk again.

Nothing wrong can happen the next two weeks.

Iavor


Sat, 11 May 2002 00:29:11 +0200
"Iavor Raytchev" <iavor.raytchev@verysmall.org>
Re: internal voting
...
> If nobody feels like managing this - let's give it a little bit of life and
> move it a bit forwards - and then talk again.

Iavor, I meant to be helpful; I was trying to put a name on The New
Group of Enthusiastic Developers Who Are Interested In Advancing
Pgaccess and shortened it to "Iavor's group". :)

> Nothing wrong can happen the next two weeks.

Certainly true. As The Developers Who Are Always Interested In Advancing
PostgreSQL And Really Like Pgaccess, we have just been trying to be
helpful and to make TNGoEDWAIIAP feel welcome to take advantage of any
existing or new resources in postgresql.org which they might want. So,
please know that TDWAAIIAPARLP are happy to support anything that
TNGoEDWAIIAP might want to do.

Regards.

                   - Thomas

Fri, 10 May 2002 16:32:24 -0700
Thomas Lockhart <lockhart@fourpalms.org>
Re: internal voting
Thomas :)))

In Europe it is 1:40 a.m.

Wish you a good night :)

And thanks,

Iavor

--
TNGoEDWAIIAP

-----Original Message-----
From: lockhart@fourpalms.org [mailto:lockhart@fourpalms.org]
Sent: Saturday, May 11, 2002 1:32 AM
To: Iavor Raytchev
Cc: pgsql-hackers; Tom Lane; Stanislav Grozev; Ross J. Reedstrom; Nigel
J. Andrews; Marc G. Fournier; Constantin Teodorescu; Cmaj; Boyan
Filipov; Boyan Dzambazov; Bartus. L; Brett Schwarz
Subject: Re: [HACKERS] internal voting


...
> If nobody feels like managing this - let's give it a little bit of life
and
> move it a bit forwards - and then talk again.

Iavor, I meant to be helpful; I was trying to put a name on The New
Group of Enthusiastic Developers Who Are Interested In Advancing
Pgaccess and shortened it to "Iavor's group". :)

> Nothing wrong can happen the next two weeks.

Certainly true. As The Developers Who Are Always Interested In Advancing
PostgreSQL And Really Like Pgaccess, we have just been trying to be
helpful and to make TNGoEDWAIIAP feel welcome to take advantage of any
existing or new resources in postgresql.org which they might want. So,
please know that TDWAAIIAPARLP are happy to support anything that
TNGoEDWAIIAP might want to do.

Regards.

                   - Thomas


Sat, 11 May 2002 01:44:28 +0200
"Iavor Raytchev" <iavor.raytchev@verysmall.org>
Re: internal voting
Ross J. Reedstrom writes:

> All very practical, execpt for one point: the people being pulled togther
> for this _have_ code, with nowhere to put it: they've been developing
> new features for pgaccess, on top of the stable pgsql. Tracking CVS
> tip means that the current version of pgaccess there is either broken
> by underlying pgsql changes (I think that is currently true with Tom's
> schema work) or does not work with the current stable version og pgsql.

We went through a very similar situation with the JDBC driver a release
ago.  A number of people had developed fixes or features for the driver
and no one was collecting them.  We've got those people working on the 7.2
branch and everything worked out well.  Yes, this meant that the features
and fixes were not immediately available in the 7.1 branch.  But the
alternative of forking pgaccess now is that the available fixes and
features will not be available in the 7.3 branch for quite a while.

-- 
Peter Eisentraut   peter_e@gmx.net


Sat, 11 May 2002 14:15:48 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: internal voting
On 2002.05.11 14:15 Peter Eisentraut wrote:
> Ross J. Reedstrom writes:
> 
> > All very practical, execpt for one point: the people being pulled
> togther
> > for this _have_ code, with nowhere to put it: they've been
> developing
> > new features for pgaccess, on top of the stable pgsql. Tracking CVS
> > tip means that the current version of pgaccess there is either
> broken
> > by underlying pgsql changes (I think that is currently true with
> Tom's
> > schema work) or does not work with the current stable version og
> pgsql.
> 
> We went through a very similar situation with the JDBC driver a
> release
> ago.  A number of people had developed fixes or features for the
> driver
> and no one was collecting them.  We've got those people working on the
> 7.2
> branch and everything worked out well.  Yes, this meant that the
> features
> and fixes were not immediately available in the 7.1 branch.  But the
> alternative of forking pgaccess now is that the available fixes and
> features will not be available in the 7.3 branch for quite a while.
> 
But we have fixes and patches for this (7.2) version, why we sould wait
for the next version. I think, there is no connection (should not be)
between the versions of the pgaccess and the versions of the pgsql.
Pgaccess is a visual tool for pgsql, that can be developed freely
without having anything to do with the pgsql developement.
So I cannot understand why the majority of the oppinions says that
pgaccess should stay in the shadow of the pgsql.
Breaking this tight connection we can help pgaccess to develop as fast
as it can, and we let free space for other projects to appear. For me
the first thing is to make my daily job as good and fast as I can. And
this is much easier with using the best tool for the particular
problem. This is why I started to make patches to this project.
Sorry but I can't wait for the next pgsql release to have this patches 
included in the package.

> --
> Peter Eisentraut   peter_e@gmx.net
> 
> 

Sat, 11 May 2002 14:36:17 +0200
Bartus Levente <bartus.l@bitel.hu>
Re: internal voting
Peter Eisentraut <peter_e@gmx.net> writes:
> We went through a very similar situation with the JDBC driver a release
> ago.  A number of people had developed fixes or features for the driver
> and no one was collecting them.  We've got those people working on the 7.2
> branch and everything worked out well.  Yes, this meant that the features
> and fixes were not immediately available in the 7.1 branch.

Au contraire --- what the JDBC folk did (and still are doing) was to
make "unofficial" releases consisting of snapshots pulled from their
chunk of the CVS tree.  There were people making use of the "7.2 branch"
of JDBC long before the 7.2 server went beta, let alone final.

Now this worked only because the JDBC driver makes a point of working
with older server versions as well as current, so it was possible to
use the updated driver with 7.1 and even older servers.  I don't know
whether pgaccess does or should have a similar policy, but if it does
then the same approach should work well for it.

The alternative of maintaining a separate CVS tree and a separate
release schedule would really force exactly that policy on pgaccess
anyway --- if your releases aren't tied to the server's then you can
hardly expect to be sure which server version people will try to use
your code with.

On the other hand, if the pgaccess developers would rather maintain
separate pgaccess versions for each server version, I see no reason
why they couldn't do that in the context of our CVS.  They could work
in the REL7_2 branch for now (and make releases from it) then merge
forward to HEAD when they want to start thinking about 7.3 issues.
Or double-patch if they want to work on both versions concurrently.

			regards, tom lane

Sat, 11 May 2002 11:15:02 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: internal voting 
On Sat, 11 May 2002, Tom Lane wrote:

> Au contraire --- what the JDBC folk did (and still are doing) was to
> make "unofficial" releases consisting of snapshots pulled from their
> chunk of the CVS tree.  There were people making use of the "7.2 branch"
> of JDBC long before the 7.2 server went beta, let alone final.
> 
> Now this worked only because the JDBC driver makes a point of working
> with older server versions as well as current, so it was possible to
> use the updated driver with 7.1 and even older servers.  I don't know
> whether pgaccess does or should have a similar policy, but if it does
> then the same approach should work well for it.

Ah, I'm just composing an email on this subject destined for the -interfaces
list.

> 
> The alternative of maintaining a separate CVS tree and a separate
> release schedule would really force exactly that policy on pgaccess
> anyway --- if your releases aren't tied to the server's then you can
> hardly expect to be sure which server version people will try to use
> your code with.
> 
> On the other hand, if the pgaccess developers would rather maintain
> separate pgaccess versions for each server version, I see no reason
> why they couldn't do that in the context of our CVS.  They could work
> in the REL7_2 branch for now (and make releases from it) then merge
> forward to HEAD when they want to start thinking about 7.3 issues.
> Or double-patch if they want to work on both versions concurrently.

Really, I'd like interested parties to have look at waht I'm posting to
-interfaces so they can shoot down my ideas on this.


-- 
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants


Sat, 11 May 2002 16:51:52 +0100 (BST)
"Nigel J. Andrews" <nandrews@investsystems.co.uk>
Re: internal voting

[Note, I've changed the headers so everyone on the original distribution list
is getting a copy via Bcc, including -hackers. It was the simplest way I could
think of making certain the discussion moved to -interfaces as Marc requested.]


On Sat, 11 May 2002, Bartus Levente wrote:
> ... I think, there is no connection (should not be)
> between the versions of the pgaccess and the versions of the pgsql.
> Pgaccess is a visual tool for pgsql, that can be developed freely
> without having anything to do with the pgsql developement.

Yes.

> So I cannot understand why the majority of the oppinions says that
> pgaccess should stay in the shadow of the pgsql.

Who said shadow? FWIW, I'd never have bothered about pgaccess, that's even I'd
even known about it, if it hadn't come in the main postgres tree.

> Breaking this tight connection we can help pgaccess to develop as fast
> as it can, and we let free space for other projects to appear. For me
> the first thing is to make my daily job as good and fast as I can. And
> this is much easier with using the best tool for the particular
> problem. This is why I started to make patches to this project.
> Sorry but I can't wait for the next pgsql release to have this patches 
> included in the package.

Uhoh, now we have a problem, unless your version is going to form the
initial repository or there's little or no impact across the preexisting code.


-- 
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants


Sat, 11 May 2002 19:27:30 +0100 (BST)
"Nigel J. Andrews" <nandrews@investsystems.co.uk>
Re: internal voting
On 2002.05.11 20:27 Nigel J. Andrews wrote:
> 
> [Note, I've changed the headers so everyone on the original
> distribution list
> is getting a copy via Bcc, including -hackers. It was the simplest way
> I could
> think of making certain the discussion moved to -interfaces as Marc
> requested.]
> 
> 
> On Sat, 11 May 2002, Bartus Levente wrote:
> > ... I think, there is no connection (should not be)
> > between the versions of the pgaccess and the versions of the pgsql.
> > Pgaccess is a visual tool for pgsql, that can be developed freely
> > without having anything to do with the pgsql developement.
> 
> Yes.
> 
> > So I cannot understand why the majority of the oppinions says that
> > pgaccess should stay in the shadow of the pgsql.
> 
> Who said shadow? FWIW, I'd never have bothered about pgaccess, that's
> even I'd
> even known about it, if it hadn't come in the main postgres tree.
> 
> > Breaking this tight connection we can help pgaccess to develop as
> fast
> > as it can, and we let free space for other projects to appear. For
> me
> > the first thing is to make my daily job as good and fast as I can.
> And
> > this is much easier with using the best tool for the particular
> > problem. This is why I started to make patches to this project.
> > Sorry but I can't wait for the next pgsql release to have this
> patches
> > included in the package.
> 
> Uhoh, now we have a problem, unless your version is going to form the
> initial repository or there's little or no impact across the
> preexisting code.
> 

Sure, there is a problem, that's why the whole discussion started. A 
software project stalled for at least a year. Why? There is no need for 
it? I can hardly beleive.

Sorry, but I cannot understand your last sentence. Could you explain to 
me, please?

I don't want to hurt anybody's feelings, I just want to help this 
software to be better, nothing more.

> --
> Nigel J. Andrews
> Director
> 
> ---
> Logictree Systems Limited
> Computer Consultants
> 
> 

Best regards,
Levi.

Sat, 11 May 2002 20:51:45 +0200
Bartus Levente <bartus.l@bitel.hu>
Re: [HACKERS] internal voting

On Sat, 11 May 2002, Bartus Levente wrote:

> On 2002.05.11 20:27 Nigel J. Andrews wrote:

> > On Sat, 11 May 2002, Bartus Levente wrote:
> > >  [snip]
> > > problem. This is why I started to make patches to this project.
> > > Sorry but I can't wait for the next pgsql release to have this
> > > patches included in the package.
> > 
> > Uhoh, now we have a problem, unless your version is going to form the
> > initial repository or there's little or no impact across the
> > preexisting code.
> 
>  [snip]
>
> Sorry, but I cannot understand your last sentence. Could you explain to 
> me, please?

All I mean is that if your patches are making major changes to the majority of
the files making up pgaccess and that the new CVS repository is going to be
initialised from a version that does not have your patches _and_ that this
initial version has been patched by others then there is possibly going to be a
lot of work to bring your patches into CVS. On the hand I suppose this could
just be viewed as the normal problem of merging patches so I'm inclined to not
worry. However, if people are working on pgaccess at the moment then
it is a good idea that their work is applied to pgaccess in the postgres tree
so everyone else can get their hands on it while we wait for the new CVS.

I am assuming here that there is a new CVS repository coming along for
pgaccess, that it will be initialised with the code from the postgres tree [and
that pgaccess in the postgres tree will be synchronised frequently].

> I don't want to hurt anybody's feelings, I just want to help this 
> software to be better, nothing more.

Mine aren't hurt :)


-- 
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants


Sat, 11 May 2002 22:57:45 +0100 (BST)
"Nigel J. Andrews" <nandrews@investsystems.co.uk>
Re: [HACKERS] internal voting
On 2002.05.11 23:57 Nigel J. Andrews wrote:
> 
> On Sat, 11 May 2002, Bartus Levente wrote:
> 
> > On 2002.05.11 20:27 Nigel J. Andrews wrote:
> 
> > > On Sat, 11 May 2002, Bartus Levente wrote:
> > > >  [snip]
> > > > problem. This is why I started to make patches to this project.
> > > > Sorry but I can't wait for the next pgsql release to have this
> > > > patches included in the package.
> > >
> > > Uhoh, now we have a problem, unless your version is going to form
> the
> > > initial repository or there's little or no impact across the
> > > preexisting code.
> >
> >  [snip]
> >
> > Sorry, but I cannot understand your last sentence. Could you explain
> to
> > me, please?
> 
> All I mean is that if your patches are making major changes to the
> majority of
> the files making up pgaccess and that the new CVS repository is going
> to be
> initialised from a version that does not have your patches _and_ that
> this
> initial version has been patched by others then there is possibly
> going to be a
> lot of work to bring your patches into CVS. On the hand I suppose this
> could
> just be viewed as the normal problem of merging patches so I'm
> inclined to not
> worry. However, if people are working on pgaccess at the moment then
> it is a good idea that their work is applied to pgaccess in the
> postgres tree
> so everyone else can get their hands on it while we wait for the new
> CVS.

We would like to merge our patches into the last release of the 
pgaccess (apperently this is now in the postgres tree), and make this 
for the future patches too.
So we set up pgaccess.org, with it's own cvs, mailing lists and 
homepage. When Iavor searched for the last release almost a war started.

> 
> I am assuming here that there is a new CVS repository coming along for
> pgaccess, that it will be initialised with the code from the postgres
> tree [and
> that pgaccess in the postgres tree will be synchronised frequently].
> 

We would like to syncronise the postgres tree, and to give people a 
place where they can find the software, tha latest release, can drop 
wishes, and browse the to-do list easier. Is there any to-do list in 
the postgres package regarding the pgaccess?

> > I don't want to hurt anybody's feelings, I just want to help this
> > software to be better, nothing more.
> 
> Mine aren't hurt :)
> 
> 
> --
> Nigel J. Andrews
> Director
> 
> ---
> Logictree Systems Limited
> Computer Consultants
> 

Best regards,
Levi.

Sun, 12 May 2002 12:15:37 +0200
Bartus Levente <bartus.l@bitel.hu>
Re: [HACKERS] internal voting
Iavor Raytchev wrote:
> 
> > If and when patches for pgaccess appear in significant numbers and for
> > some reason, which I cannot imagine, this procedure doesn't end up being
> > practical, we can consider the alternatives.  But before you spend a lot
> > of time building a new infrastructure, let's see some code.
> >
> > --
> > Peter Eisentraut   peter_e@gmx.net
> 
> We are working on it, because we have some code.
> 
> Don't you believe us, or do you think we have a lot of free time to waste?
> 
> We - Chris, Bartus, Boyan and myself, have enough patches we want to merge.
> And we do not feel like asking for permisson to do it. We sent them to Teo
> and we were asked by Teo to meet and see what we can do with our patches.
> And we were nice enough to tell the world about this.
> 
> I do not feel neither like 'asking for permisson', nor like 'proving'
> anything. If somebody wants to help - is welcome.

I find that this group is frustrating to work with. They seem very intolerant
of the plurality.

I did a configuration patch several months ago. I liked it, as did some others.
It did not affect any existing behavior, but added the ability to store
configuration information in a different location than the data, and share
files between multiple PostgreSQL instances.

Rather than evaluate the patch, and say it needs these changes, or simply
applying it, you know, working with the contributor's to make a better project,
they ranted and raved how they didn't like it, how they wanted something
better, etc. No good technical reasons were given, mind you, just "I don't like
this." 

So, I did the work, for what? Nothing. It is pointless for me to make the
changes for each release. Fortunately it wasn't too much work. So, my
experience tells me that unless the work you do is something they want, you are
wasting your time. If you try to get some feedback from them about an approach
you wish to take, so you don't waste your time, they flame you and tell you to
put up or shut up.

If you intend to undertake a major work on PostgreSQL, it had better be for
something other than contribution back to the group, otherwise, there is a good
possibility that you are going to waste your time.

I do not get paid to work on PostgreSQL, the time I spend on it is either my
own or for a project I am working on. I am finding it very unsatisfying.

Mon, 13 May 2002 10:56:29 -0400
mlw <markw@mohawksoft.com>
Re: pgaccess - the discussion is over
On Mon, 13 May 2002, mlw wrote:

> Iavor Raytchev wrote:
> >
> > > If and when patches for pgaccess appear in significant numbers and for
> > > some reason, which I cannot imagine, this procedure doesn't end up being
> > > practical, we can consider the alternatives.  But before you spend a lot
> > > of time building a new infrastructure, let's see some code.
> > >
> > > --
> > > Peter Eisentraut   peter_e@gmx.net
> >
> > We are working on it, because we have some code.
> >
> > Don't you believe us, or do you think we have a lot of free time to waste?
> >
> > We - Chris, Bartus, Boyan and myself, have enough patches we want to merge.
> > And we do not feel like asking for permisson to do it. We sent them to Teo
> > and we were asked by Teo to meet and see what we can do with our patches.
> > And we were nice enough to tell the world about this.
> >
> > I do not feel neither like 'asking for permisson', nor like 'proving'
> > anything. If somebody wants to help - is welcome.
>
> I find that this group is frustrating to work with. They seem very intolerant
> of the plurality.
>
> I did a configuration patch several months ago. I liked it, as did some others.
> It did not affect any existing behavior, but added the ability to store
> configuration information in a different location than the data, and share
> files between multiple PostgreSQL instances.
>
> Rather than evaluate the patch, and say it needs these changes, or simply
> applying it, you know, working with the contributor's to make a better project,
> they ranted and raved how they didn't like it, how they wanted something
> better, etc. No good technical reasons were given, mind you, just "I don't like
> this."
>
> So, I did the work, for what? Nothing. It is pointless for me to make the
> changes for each release. Fortunately it wasn't too much work. So, my
> experience tells me that unless the work you do is something they want, you are
> wasting your time. If you try to get some feedback from them about an approach
> you wish to take, so you don't waste your time, they flame you and tell you to
> put up or shut up.
>
> If you intend to undertake a major work on PostgreSQL, it had better be for
> something other than contribution back to the group, otherwise, there is a good
> possibility that you are going to waste your time.
>
> I do not get paid to work on PostgreSQL, the time I spend on it is either my
> own or for a project I am working on. I am finding it very unsatisfying.

This is the unfortunate impression I'm getting from some people on the
HACKERS list, which is why discussion has moved temporarily to
INTERFACES until pgaccess.org has its own mailing list.  Plus that and
the fact that pgaccess is an interface to postgresql.  Also, INTERFACES
seems to be a lot more newbie questions but these people are trying to
learn so it is a more welcoming environment.

What is strange is that you weren't even talking about a fork, which
seems to be the central philosophical issue with pgaccess at the moment.
All I can say to reassure people is that it is still _PG_access, not
_access_ *ick*.

--Chris

-- 

cmaj_at_freedomcorpse_dot_info
fingerprint 5EB8 2035 F07B 3B09 5A31  7C09 196F 4126 C005 1F6A



Mon, 13 May 2002 11:49:51 -0400 (EDT)
"C. Maj" <cmaj@freedomcorpse.info>
Re: pgaccess - the discussion is over
[trimmed cc list, but left on HACKERS due to the nature of the subject (which 
was changed]
On Monday 13 May 2002 10:56 am, mlw wrote:
> Iavor Raytchev wrote:
> > Peter Eisentraut wrote:
> > > let's see some code.

> > I do not feel neither like 'asking for permisson', nor like 'proving'
> > anything. If somebody wants to help - is welcome.

> I find that this group is frustrating to work with. They seem very
> intolerant of the plurality.

> I did a configuration patch several months ago. I liked it, as did some
> others. It did not affect any existing behavior, but added the ability to
> store configuration information in a different location than the data, and
> share files between multiple PostgreSQL instances.

While I personally felt that your patch was useful, there were other concerns.

> Rather than evaluate the patch, and say it needs these changes, or simply
> applying it, you know, working with the contributor's to make a better
> project, they ranted and raved how they didn't like it, how they wanted
> something better, etc. No good technical reasons were given, mind you, just
> "I don't like this."

I think you might want to reread that thread.  There _were_ in fact technical 
aspects of the situation -- primarily due to the _plurality_ of the 
development process around here.  It isn't 'plural' to have someone announce 
that they have a patch, and then it gets applied without the discussion of 
the established developers.  No -- changes to this codebase are done by a 
plurality -- meaning the entire pgsql-hackers group.  (Well, at least that's 
how it's supposed to be -- it doesn't always work that way.....).

Your patch was discussed -- the resolution seemed to me to be in favor of 
including that functionality in 7.3.  To which I was very happy.

This isn't the Linux kernel with a benevolent dictator who can unilaterally 
apply patches -- this is an oligarchy with the six core developers, together 
with the rest of us, making those decisions as a group.  The discussions 
aren't flames -- at least I didn't take any of those discussions to be 
flames.  While there are a few opinionated ones here (myself included), we do 
tend to take things on technical merit.  Had you patch merited inclusion 
without discussion -- well, that wouldn't have happened, regardless of its 
merits -- we were in beta, IIRC.  IIRI, then I apologize.  In beta new 
features are frowned upon -- and your patch introduced a substantial new 
feature, one that needed careful thought before implemention.

While your patch works for you, as written it didn't necessarily work for 
everyone.  BTW, it would have worked great for me and my purposes, but 
PostgreSQL isn't a vehicle for my personal purposes.

The discussion I remember was a little antsy primarily due to the fact that we 
were in beta.  Then was not the time; now is.  Reintroduce the topic now, and 
let's see what happens.

> I do not get paid to work on PostgreSQL, the time I spend on it is either
> my own or for a project I am working on. I am finding it very unsatisfying.

I do not currently get paid for working on it either.  Do I find it 
satisfying?  Most of the time I do.  But if you don't find it satisfying, 
well, there could be more than one reason.

But the biggest problem I see was the inappropriate timing of the patch.  
Again, _NOW_ would be a good time to reintroduce the topic, as we're not in 
beta, and all of the developers are much more likely to be open to these 
ideas.  But go back to the previous thread in the archives and see where we 
left off first, so that everybody starts on the same page of music.

But understand that those who don't need the functionality are likely not not 
be thrilled by changes to a currently stable codebase.  Although this config 
file stuff is small potatoes compared to the Win32 stuff as recently 
discussed.  And for that, please understand that most of the developers here 
consider Win32 an inferior server platform.  In fact, Win32 _is_ an inferior 
server platform, at least in my opinion.  But, if you want to do the work, 
and it doesn't break my non-Win32 server build, by all means go for it.

With that said, I hope you'll consider sticking it out and seeing it through 
at least two major cycles.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Mon, 13 May 2002 19:05:55 -0400
Lamar Owen <lamar.owen@wgcr.org>
Discontent with development process (was:Re: pgaccess - the
	discussion is over)
Lamar Owen <lamar.owen@wgcr.org> writes:
> Although this config file stuff is small potatoes compared to the
> Win32 stuff as recently discussed.  And for that, please understand
> that most of the developers here consider Win32 an inferior server
> platform.  In fact, Win32 _is_ an inferior server platform, at least
> in my opinion.  But, if you want to do the work, and it doesn't break
> my non-Win32 server build, by all means go for it.

Note that "doesn't break non-Win32 builds" is not really the standard
that will get applied.  Ongoing readability and maintainability of the
codebase is a very high priority in my eyes, and I think in the eyes
of most of the key developers.  To the extent that Win32 support can
be added without hurting those goals, I have nothing against it.
I'll even put up with localized ugliness (see the BeOS support hacks
for an example of what I'd call localized ugliness).  But I get unhappy
when there's airy handwaving about moving all static variables into some
global data structure, to take just one of the points that were under
discussion last week.  That'd be a big maintainability penalty IMHO.

As for the more general point --- my recollection of that thread was
that mlw himself was more than a bit guilty of adopting a "my way or no
way" attitude; if he sees some pushback from the other developers maybe
he should consider the possibility that he's creating his own problem.
In general this development community is one of the most civilized I've
ever seen.  I don't think it's that hard to get consensus on most
topics.  The consensus isn't always the same as my personal opinion...
but that's the price of being part of a community.

			regards, tom lane

Mon, 13 May 2002 22:03:00 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Discontent with development process (was:Re: pgaccess - the
	discussion is over)
On Mon, 13 May 2002, Lamar Owen wrote:

> But understand that those who don't need the functionality are likely not not
> be thrilled by changes to a currently stable codebase.  Although this config
> file stuff is small potatoes compared to the Win32 stuff as recently
> discussed.  And for that, please understand that most of the developers here
> consider Win32 an inferior server platform.  In fact, Win32 _is_ an inferior
> server platform, at least in my opinion.  But, if you want to do the work,
> and it doesn't break my non-Win32 server build, by all means go for it.

Actually, even for those that wuldn't need the patch ... as long as the
"default behaviour" doesn't change, and unless there are no valid
technical arguments around it, there is no reason why a patch shouldn't be
included ...


Tue, 14 May 2002 01:13:28 -0300 (ADT)
"Marc G. Fournier" <scrappy@hub.org>
Re: Discontent with development process (was:Re: pgaccess
> Actually, even for those that wuldn't need the patch ... as long as the
> "default behaviour" doesn't change, and unless there are no valid
> technical arguments around it, there is no reason why a patch shouldn't be
> included ...

Unless it's going to interfere with implementing the general case in the
future, making it a painful feature to keep backwards-compatibility with.
Which is what the discussion was about IIRC...

Chris


Tue, 14 May 2002 12:26:01 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: Discontent with development process (was:Re: pgaccess
On Tue, 2002-05-14 at 04:03, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > Although this config file stuff is small potatoes compared to the
> > Win32 stuff as recently discussed.  And for that, please understand
> > that most of the developers here consider Win32 an inferior server
> > platform.  In fact, Win32 _is_ an inferior server platform, at least
> > in my opinion.  But, if you want to do the work, and it doesn't break
> > my non-Win32 server build, by all means go for it.
> 
> Note that "doesn't break non-Win32 builds" is not really the standard
> that will get applied.  Ongoing readability and maintainability of the
> codebase is a very high priority in my eyes, and I think in the eyes
> of most of the key developers.  To the extent that Win32 support can
> be added without hurting those goals, I have nothing against it.
> I'll even put up with localized ugliness (see the BeOS support hacks
> for an example of what I'd call localized ugliness).  But I get unhappy
> when there's airy handwaving about moving all static variables into some
> global data structure,

What would your opinion be of some hack with macros, like 

#if (Win32 or THREADED)
#define GLOBAL_ pg_globals.
#else
#define GLOBAL_
#endif

and then use global variables as

GLOBAL_globvar

At least in my opinion that would increase both readability and
maintainability.

> to take just one of the points that were under
> discussion last week.  That'd be a big maintainability penalty IMHO.

-----------------
Hannu



14 May 2002 10:21:02 +0200
Hannu Krosing <hannu@tm.ee>
Re: Discontent with development process (was:Re: pgaccess
Hannu Krosing <hannu@tm.ee> writes:
> What would your opinion be of some hack with macros, like 

> #if (Win32 or THREADED)
> #define GLOBAL_ pg_globals.
> #else
> #define GLOBAL_
> #endif

> and then use global variables as

> GLOBAL_globvar

> At least in my opinion that would increase both readability and
> maintainability.

 From a code readability viewpoint this is not at all better than just
moving everything to pg_globals.  You're only spelling "pg_globals."
a little differently.  And it introduces twin possibilities for error:
omitting GLOBAL_ (if you're a Unix developer) or writing
pg_globals. explicitly (if you're a Win32 guy).  I suppose these errors
would be caught as soon as someone tried to compile on the other
platform, but it still seems like a mess with little redeeming value.

I think there had been some talk of

#if Win32
#define myvar  pg_globals.f_myvar
#else
static int myvar;
#endif

which seems a more effective use of macros --- it would at least allow
the code to be written without explicit awareness of the special status
of the variable.  Still seems like a maintenance nightmare though.

The real problem with airily saying "we'll just move that variable to
pg_globals" is that it falls down the instant that you consider
non-scalar variables.  What if it's a pointer to a palloc'd structure?
Sure we can get around this, but not transparently.

			regards, tom lane

Tue, 14 May 2002 09:52:47 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Discontent with development process (was:Re: pgaccess - the
	discussion is over)
Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > Although this config file stuff is small potatoes compared to the
> > Win32 stuff as recently discussed.  And for that, please understand
> > that most of the developers here consider Win32 an inferior server
> > platform.  In fact, Win32 _is_ an inferior server platform, at least
> > in my opinion.  But, if you want to do the work, and it doesn't break
> > my non-Win32 server build, by all means go for it.
>
> Note that "doesn't break non-Win32 builds" is not really the standard
> that will get applied.  Ongoing readability and maintainability of the
> codebase is a very high priority in my eyes, and I think in the eyes
> of most of the key developers.  To the extent that Win32 support can
> be added without hurting those goals, I have nothing against it.

    The  tricky  twist  will  be  to  keep good readability while
    taking different solution approaches  for  different  Systems
    (e.g.  fork()  only for *NIX vs. CreateProcess() for Win).  I
    agree that your high priority goal is a  good  one.  Thinking
    about good old Unix semantics, having a higher priority means
    not beeing as nice as others, right? Then  again,  even  with
    the  lowest possible nice level a process doesn't own the CPU
    exclusively (so it never becomes rude).

> I'll even put up with localized ugliness (see the BeOS support hacks
> for an example of what I'd call localized ugliness).  But I get unhappy
> when there's airy handwaving about moving all static variables into some
> global data structure, to take just one of the points that were under
> discussion last week.  That'd be a big maintainability penalty IMHO.

    As I understood it  the  idea  was  to  put  the  stuff,  the
    backends  inherit  from  the  postmaster,  into a centralized
    place, instead of having it spread out all  over  the  place.
    What's wrong with that?

> As for the more general point --- my recollection of that thread was
> that mlw himself was more than a bit guilty of adopting a "my way or no
> way" attitude; if he sees some pushback from the other developers maybe
> he should consider the possibility that he's creating his own problem.
> In general this development community is one of the most civilized I've
> ever seen.  I don't think it's that hard to get consensus on most
> topics.  The consensus isn't always the same as my personal opinion...
> but that's the price of being part of a community.

    Yeah, maybe democracy wasn't such a perfect idea at all ...


Jan ;-)

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



Tue, 14 May 2002 10:17:31 -0400 (EDT)
Jan Wieck <janwieck@yahoo.com>
Re: Discontent with development process (was:Re: pgaccess
Jan Wieck <janwieck@yahoo.com> writes:
>     As I understood it  the  idea  was  to  put  the  stuff,  the
>     backends  inherit  from  the  postmaster,  into a centralized
>     place, instead of having it spread out all  over  the  place.
>     What's wrong with that?

The main objection to it in my mind is that what had been private
variables in specific modules now become exceedingly public.  Instead of
looking at "static int foo" and *knowing* that all the references are in
the current file, you have to go trolling the entire backend to see who
is referencing pg_globals.foo.

I have not counted to see how many variables are really affected; if
there's only a few then it doesn't matter much.  But the people who
have done this so far have all reported inserting tons of #ifdefs,
which leads me to the assumption that there's a lot of 'em.

			regards, tom lane

Tue, 14 May 2002 10:30:07 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Discontent with development process (was:Re: pgaccess - the
	discussion is over)


Tom Lane wrote:

>Hannu Krosing <hannu@tm.ee> writes:
>
>>What would your opinion be of some hack with macros, like 
>>
>
>>#if (Win32 or THREADED)
>>#define GLOBAL_ pg_globals.
>>#else
>>#define GLOBAL_
>>#endif
>>
>
>>and then use global variables as
>>
>
>>GLOBAL_globvar
>>
>
>>At least in my opinion that would increase both readability and
>>maintainability.
>>
>
>>From a code readability viewpoint this is not at all better than just
>moving everything to pg_globals.  You're only spelling "pg_globals."
>a little differently.  And it introduces twin possibilities for error:
>omitting GLOBAL_ (if you're a Unix developer) or writing
>pg_globals. explicitly (if you're a Win32 guy).  I suppose these errors
>would be caught as soon as someone tried to compile on the other
>platform, but it still seems like a mess with little redeeming value.
>

Another suggestion might be to create a global hashtable that stores the 
size and pointer
to global structures for each subsection.  Each subsection can define 
its own globals
structure and register them with the hashtable.  This would not impact 
readablity and
make the gobal environment easy to copy.  IMHO, this is possible with 
minimal performance
impact.

Myron Scott
mkscott@sacadia.com



Tue, 14 May 2002 07:54:36 -0700
Myron Scott <mkscott@sacadia.com>
Re: Discontent with development process (was:Re: pgaccess - the
	discussion is over)
Myron Scott <mkscott@sacadia.com> writes:
> Another suggestion might be to create a global hashtable that stores
> the size and pointer to global structures for each subsection.  Each
> subsection can define its own globals structure and register them with
> the hashtable.

Hmm ... now *that* is an interesting idea.

With a little more intelligence in the manager of this table, this could
also solve my concern about pointer variables.  Perhaps the entries
could include not just address/size but some type information.  If the
manager knows "this variable is a pointer to a palloc'd string" then it
could do the Right Thing during fork.  Not sure offhand what the
categories would need to be, but we could derive those if anyone has
cataloged the variables that get passed down from postmaster to children.

I don't think it needs to be a hashtable --- you wouldn't ever be doing
lookups in it, would you?  Just a simple list of things-to-copy ought to
do fine.

			regards, tom lane

Tue, 14 May 2002 11:59:32 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Discontent with development process (was:Re: pgaccess - the
	discussion is over)


Tom Lane wrote:

>
>
>With a little more intelligence in the manager of this table, this could
>also solve my concern about pointer variables.  Perhaps the entries
>could include not just address/size but some type information.  If the
>manager knows "this variable is a pointer to a palloc'd string" then it
>could do the Right Thing during fork.  Not sure offhand what the
>categories would need to be, but we could derive those if anyone has
>cataloged the variables that get passed down from postmaster to children.
>
>I don't think it needs to be a hashtable --- you wouldn't ever be doing
>lookups in it, would you?  Just a simple list of things-to-copy ought to
>do fine.
>	
>
I'm thinking in a threaded context where a method may need to lookup a
global that is not passed in.  But for copying, I suppose no lookups 
would be
neccessary.


Myron Scott
mkscott@sacadia.com



Tue, 14 May 2002 09:17:58 -0700
Myron Scott <mkscott@sacadia.com>
Re: Discontent with development process (was:Re: pgaccess - the
	discussion is over)


Mark (mlw) ... could you generate a listing of those variables you feel
would need to be moved to a 'global structure' and post that to the list?
That would at least give us a starting point, instead of both sides
guessing at what is/would be involved ...


On Tue, 14 May 2002, Tom Lane wrote:

> Jan Wieck <janwieck@yahoo.com> writes:
> >     As I understood it  the  idea  was  to  put  the  stuff,  the
> >     backends  inherit  from  the  postmaster,  into a centralized
> >     place, instead of having it spread out all  over  the  place.
> >     What's wrong with that?
>
> The main objection to it in my mind is that what had been private
> variables in specific modules now become exceedingly public.  Instead of
> looking at "static int foo" and *knowing* that all the references are in
> the current file, you have to go trolling the entire backend to see who
> is referencing pg_globals.foo.
>
> I have not counted to see how many variables are really affected; if
> there's only a few then it doesn't matter much.  But the people who
> have done this so far have all reported inserting tons of #ifdefs,
> which leads me to the assumption that there's a lot of 'em.
>
> 			regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>


Tue, 14 May 2002 13:29:23 -0300 (ADT)
"Marc G. Fournier" <scrappy@hub.org>
Global Variables (Was: Re: Discontent with development process
	(was:Re: pgaccess - the discussion is over) )
"Marc G. Fournier" wrote:
> 
> Mark (mlw) ... could you generate a listing of those variables you feel
> would need to be moved to a 'global structure' and post that to the list?
> That would at least give us a starting point, instead of both sides
> guessing at what is/would be involved ...

(1) All the configuration info.
(2) All the globals in postmaster.c
(3) Make sure that memory contexts are initialized correctly.
(4) Exception handling.
(5) Make sure that the statistics and other child processes work too.

In BackendStartup(), rather than "pid = fork();" You should split the routine
at that point, one end will be called for error and successful exec of child
process, another will be called for the child.

On UNIX, it will merely be a slight rearrangement of the code. On Windows it
will represent a different function which will copy the globals from the
parent, and call in. Think of it like this:

Currently it looks something like this:

BackendStartup(port)
{
	....
	pid = fork();

	if( pid < 0)
		// error
	else if(pid )
		// Still in Parent
	else
		// Do child	
}

This would have to change to this:

BackendStartup(port)
{
	...

	pid = StartBackendProcess(port);

	if(pid < 0)
		// Error
	else if(pid)
		// Still in Parent
	else
		exit(DoBackend()); // Will never happen on Windows.
}

#ifdef WIN32
StartBackendProcess(port)
{
	HANDLE hprocess= CreateProcess("...../postgres", ....);

	(initialize process here)
	return hprocess;
}
#endif
#ifdef HAS_FORK
StartBackendProcess(port)
{
	return fork();
}
#endif

In the main code (src/backend/main), you would have to pass a parameter to the
backend to inform it that is being started as a child of the postmaster, and to
call DoBackend() under windows. MPI does this sort of thing.

I see the whole thing as fairly straight forward. Fork is nothing more than a
copy. We should be able to identify what postmaster does prior to the fork of a
backend. The tricks are to handle the shared memory and semaphores, but those
are easy too. We could create a DLL for Postgres which has implicitly shared
data amongst the processes, and make sure that Postmaster updates all the
shared data prior to entering its server loop. That way the backends are only
reading data from a shared resource.

Once the Windows version of PostgreSQL is able to exec the child, I think the
areas where there are things that were missed should be pretty obvious.

It should take a pretty good engineer a few (full time, 40+ hours) weeks. It
should be mostly done the first week, the last two weeks would be chasing bugs
created by variables that were not initialized. This assumes, of course, that
you are using a cygwin build environment without the cygwin or cygipc dlls. If
we were to use MS C/C++ it would take a much longer time, although ultimately
that may be the desired direction.

P.S.
I have unsubscribed from the hackers list, if you wish to contact me, use my
email address directly.

Tue, 14 May 2002 13:55:19 -0400
mlw <markw@mohawksoft.com>
Re: Global Variables (Was: Re: Discontent with development 
On Tue, 14 May 2002, Myron Scott wrote:

>
>
> Tom Lane wrote:
>
> >
> >
> >With a little more intelligence in the manager of this table, this could
> >also solve my concern about pointer variables.  Perhaps the entries
> >could include not just address/size but some type information.  If the
> >manager knows "this variable is a pointer to a palloc'd string" then it
> >could do the Right Thing during fork.  Not sure offhand what the
> >categories would need to be, but we could derive those if anyone has
> >cataloged the variables that get passed down from postmaster to children.
> >
> >I don't think it needs to be a hashtable --- you wouldn't ever be doing
> >lookups in it, would you?  Just a simple list of things-to-copy ought to
> >do fine.
> >
> >

> I'm thinking in a threaded context where a method may need to lookup a
> global that is not passed in.  But for copying, I suppose no lookups
> would be neccessary.

if we can, can we keep the whole 'threaded' concept in mind when
developing this ... if going a hashtable would be required for this, let's
go the more complete route and eliminate potential issues down the road
...




Wed, 15 May 2002 00:45:26 -0300 (ADT)
"Marc G. Fournier" <scrappy@hub.org>
Re: Discontent with development process (was:Re: pgaccess