Christopher Kings-Lynne wrote:
>> I think Martin Oosterhout's nearby email on coverity bug reports might
>> make a good SoC project, but should it also be added to the TODO list?
>
>
> I may as well put up phpPgAdmin for it. We have plenty of projects
> available in phpPgAdmin...

Same with pgAdmin3.

Regards,
Andreas

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

http://archives.postgresql.org

On Fri, Apr 21, 2006 at 10:27:48AM +0200, Andreas Pflug wrote:
> Christopher Kings-Lynne wrote:
> >>I think Martin Oosterhout's nearby email on coverity bug reports might
> >>make a good SoC project, but should it also be added to the TODO list?
> >
> >
> >I may as well put up phpPgAdmin for it. We have plenty of projects
> >available in phpPgAdmin...
>
> Same with pgAdmin3.

Is there a list of specific projects? I'm pretty sure we can't just say
"work on (pgp)PgAdmin...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

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

http://archives.postgresql.org

Robert and I are working on updating it ASAP.

On 4/21/06, Jim C. Nasby <jnasby@pervasive.com> wrote:
> On Fri, Apr 21, 2006 at 10:27:48AM +0200, Andreas Pflug wrote:
> > Christopher Kings-Lynne wrote:
> > >>I think Martin Oosterhout's nearby email on coverity bug reports might
> > >>make a good SoC project, but should it also be added to the TODO list?
> > >
> > >
> > >I may as well put up phpPgAdmin for it. We have plenty of projects
> > >available in phpPgAdmin...
> >
> > Same with pgAdmin3.
>
> Is there a list of specific projects? I'm pretty sure we can't just say
> "work on (pgp)PgAdmin...
> --
> Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
> Pervasive Software http://pervasive.com work: 512-231-6117
> vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
>


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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Friday 21 April 2006 14:11, Jim C. Nasby wrote:
> On Fri, Apr 21, 2006 at 10:27:48AM +0200, Andreas Pflug wrote:
> > Christopher Kings-Lynne wrote:
> > >>I think Martin Oosterhout's nearby email on coverity bug reports might
> > >>make a good SoC project, but should it also be added to the TODO list?
> > >
> > >I may as well put up phpPgAdmin for it. We have plenty of projects
> > >available in phpPgAdmin...
> >
> > Same with pgAdmin3.
>
> Is there a list of specific projects? I'm pretty sure we can't just say
> "work on (pgp)PgAdmin...

http://www.postgresql.org/developer/summerofcode

--
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

On Fri, Apr 21, 2006 at 05:48:33PM -0400, Robert Treat wrote:
> On Friday 21 April 2006 14:11, Jim C. Nasby wrote:
> > On Fri, Apr 21, 2006 at 10:27:48AM +0200, Andreas Pflug wrote:
> > > Christopher Kings-Lynne wrote:
> > > >>I think Martin Oosterhout's nearby email on coverity bug reports might
> > > >>make a good SoC project, but should it also be added to the TODO list?
> > > >
> > > >I may as well put up phpPgAdmin for it. We have plenty of projects
> > > >available in phpPgAdmin...
> > >
> > > Same with pgAdmin3.
> >
> > Is there a list of specific projects? I'm pretty sure we can't just say
> > "work on (pgp)PgAdmin...
>
> http://www.postgresql.org/developer/summerofcode

Want to replace

<li><strong>Many TODO Items</strong>A number of the items on our TODO
list have been marked as good projects for beginners whos are new to the
PostgreSQL code. Items on this list have the advantage of already having
general community agreement that the feature is desireable. These items
should also have some general discussion available in the mailing list
archives to help get you started. You can find these items on the <a
href="http://wwwmaster.postgresql.org/docs/faqs.TODO.html">TODO</a>
list, they will be marked with apercent sign (%).
</li>

with

<li><strong>Many TODO Items</strong>: A number of the items on our TODO
list have been marked as good projects for beginners who are new to the
PostgreSQL code. Items on this list have the advantage of already having
general community agreement that the feature is desireable. These items
should also have some general discussion available in the mailing list
archives to help get you started. You can find these items on the <a
href="http://wwwmaster.postgresql.org/docs/faqs.TODO.html">TODO</a>
list, they will be marked with apercent sign (%).
</li>

?
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Jim C. Nasby wrote:
>>
>> Same with pgAdmin3.
>>
>
> Is there a list of specific projects? I'm pretty sure we can't just say
> "work on (pgp)PgAdmin...
>

Our TODO list has some.

Regards,
Andreas



---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

I hope I'm not too late.

Jonah H. Harris wrote:
> On 4/19/06, John DeSoi <desoi@pgedit.com> wrote:
> > Alvaro indicated he would be willing to provide direction on this
> > with testing support from me. He also said there are several other
> > possible PL/PHP issues that would warrant a SoC project.
>
> Cool... let's get 'em all listed here so we can move forward.

The following is all PL/php related, in no particular order:

1. Add support for IN/OUT parameters, and named parameters. This should
be easy to do, the majority of needed infraestructure in PL/php is there
already. It only needs a bit more love.

2. Clean up memory usage. Both compilation and execution of a function
should happen on separate, maybe temporary, memory contexts; and provide
adequate cleanup for both (for example when a function is recompiled).

3. Enable it to build separate from the Apache SAPI.

4. Allow huge resultsets to be processed by providing an option to
transparently use a cursor to fetch results partially, when spi_exec()
is called.

5. Clean up the plphp_proc_desc struct. This involves making sure we
store all the info we need to know about a function; no more, no less.
(I think currently we store things we don't need, and we don't store
some things it would be useful to know).


I don't think any of these would warrant a SoC by itself. Maybe the
whole bunch could, however.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(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

Cool... will get them added.

On 4/23/06, Alvaro Herrera <alvherre@commandprompt.com> wrote:
> I hope I'm not too late.
>
> Jonah H. Harris wrote:
> > On 4/19/06, John DeSoi <desoi@pgedit.com> wrote:
> > > Alvaro indicated he would be willing to provide direction on this
> > > with testing support from me. He also said there are several other
> > > possible PL/PHP issues that would warrant a SoC project.
> >
> > Cool... let's get 'em all listed here so we can move forward.
>
> The following is all PL/php related, in no particular order:
>
> 1. Add support for IN/OUT parameters, and named parameters. This should
> be easy to do, the majority of needed infraestructure in PL/php is there
> already. It only needs a bit more love.
>
> 2. Clean up memory usage. Both compilation and execution of a function
> should happen on separate, maybe temporary, memory contexts; and provide
> adequate cleanup for both (for example when a function is recompiled).
>
> 3. Enable it to build separate from the Apache SAPI.
>
> 4. Allow huge resultsets to be processed by providing an option to
> transparently use a cursor to fetch results partially, when spi_exec()
> is called.
>
> 5. Clean up the plphp_proc_desc struct. This involves making sure we
> store all the info we need to know about a function; no more, no less.
> (I think currently we store things we don't need, and we don't store
> some things it would be useful to know).
>
>
> I don't think any of these would warrant a SoC by itself. Maybe the
> whole bunch could, however.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>
> ---------------------------(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
>


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

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

http://archives.postgresql.org

Where do we stand with getting much more reasonable default values in
postgresql.conf? Maybe that should be a SoC project, or is it too small?
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

"Jim C. Nasby" <jnasby@pervasive.com> writes:
> Where do we stand with getting much more reasonable default values in
> postgresql.conf? Maybe that should be a SoC project, or is it too small?

Define "much more reasonable".

I doubt this is SoC material, simply because the issues have little to
do with coding and a lot to do with persuading people to drop default
support for old platforms. Which is not something a student is likely
to succeed at.

regards, tom lane

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

http://archives.postgresql.org