Re: [COMMITTERS] pgsql: Make configuration parameters fall back to their default values

Log Message:
-----------
Make configuration parameters fall back to their default values when they
are removed from the configuration file.

Joachim Wieland

Modified Files:
--------------
pgsql/src/backend/access/transam:
xact.c (r1.234 -> r1.235)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xact.c.diff?r1=1.234&r2=1.235)
pgsql/src/backend/utils/misc:
guc-file.l (r1.47 -> r1.48)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc-file.l.diff?r1=1.47&r2=1.48)
guc.c (r1.379 -> r1.380)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c.diff?r1=1.379&r2=1.380)
pgsql/src/include/utils:
guc_tables.h (r1.30 -> r1.31)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/guc_tables.h.diff?r1=1.30&r2=1.31)

petere(at)postgresql(dot)org (Peter Eisentraut) writes:
> Make configuration parameters fall back to their default values when they
> are removed from the configuration file.

It appears that this patch has broken custom GUC variables; at the very
least it's broken plperl.

regards, tom lane

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> petere(at)postgresql(dot)org (Peter Eisentraut) writes:
>> Make configuration parameters fall back to their default values when they
>> are removed from the configuration file.
>
> It appears that this patch has broken custom GUC variables; at the very
> least it's broken plperl.

Huh, it occurs to me that I haven't seen any plperl regression tests fly by
when I've been running regression tests myself. What do I have to do to test
if plperl, plpython, etc work with the packed varlena patch?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

Gregory Stark wrote:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
>> petere(at)postgresql(dot)org (Peter Eisentraut) writes:
>>> Make configuration parameters fall back to their default values when
>>> they
>>> are removed from the configuration file.
>>
>> It appears that this patch has broken custom GUC variables; at the very
>> least it's broken plperl.
>
> Huh, it occurs to me that I haven't seen any plperl regression tests fly
> by
> when I've been running regression tests myself. What do I have to do to
> test
> if plperl, plpython, etc work with the packed varlena patch?
>

cd src/pl; make installcheck

cheers

andrew

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Huh, it occurs to me that I haven't seen any plperl regression tests fly by
> when I've been running regression tests myself. What do I have to do to test
> if plperl, plpython, etc work with the packed varlena patch?

cd to $TOP/src/pl, run "make installcheck". Make sure you have
configured --with all the PLs you want to test.

regards, tom lane

On Mon, Mar 12, 2007 at 08:20:53PM -0500, Andrew Dunstan wrote:
> Gregory Stark wrote:
> > "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> >
> >> petere(at)postgresql(dot)org (Peter Eisentraut) writes:
> >>> Make configuration parameters fall back to their default values when
> >>> they
> >>> are removed from the configuration file.
> >>
> >> It appears that this patch has broken custom GUC variables; at the very
> >> least it's broken plperl.
> >
> > Huh, it occurs to me that I haven't seen any plperl regression tests fly
> > by
> > when I've been running regression tests myself. What do I have to do to
> > test
> > if plperl, plpython, etc work with the packed varlena patch?
> >
>
>
> cd src/pl; make installcheck

Is there any particular reason why we don't run these as part of a
general "make check"?

//Magnus

Magnus Hagander wrote:
> On Mon, Mar 12, 2007 at 08:20:53PM -0500, Andrew Dunstan wrote:
>
>> Gregory Stark wrote:
>>
>>> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>>>
>>>
>>>> petere(at)postgresql(dot)org (Peter Eisentraut) writes:
>>>>
>>>>> Make configuration parameters fall back to their default values when
>>>>> they
>>>>> are removed from the configuration file.
>>>>>
>>>> It appears that this patch has broken custom GUC variables; at the very
>>>> least it's broken plperl.
>>>>
>>> Huh, it occurs to me that I haven't seen any plperl regression tests fly
>>> by
>>> when I've been running regression tests myself. What do I have to do to
>>> test
>>> if plperl, plpython, etc work with the packed varlena patch?
>>>
>>>
>> cd src/pl; make installcheck
>>
>
> Is there any particular reason why we don't run these as part of a
> general "make check"?
>
> //Magnus
>
>

Probably historical more than anything else.

The core tests all run regardless of configuration, though, and the PL
tests use a different database (by design). When we standardised this we
did just enough to enable the buildfarm clients to test PLs sanely. If
you think we need more, have a go at it.

I should perhaps point out that the buildfarm client can be used to do a
comprehensive build and test on your sources, including all the
configured PLs, ECPG and the contrib tests, using either the
--from-source or --from-source-clean flags. These were originally
designed to help diagnose and fix problems disclosed during normal
buildfarm runs, but I have found it quite useful when working on
substantial projects. You don't need to be registered as a buildfarm
member to use the client program, in these modes - no results are
uploaded to the server when these flags are used.

cheers

andrew