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

2007-03-13 Thread Magnus Hagander
On Mon, Mar 12, 2007 at 08:20:53PM -0500, Andrew Dunstan wrote:
 Gregory Stark wrote:
  Tom Lane [EMAIL PROTECTED] writes:
 
  [EMAIL PROTECTED] (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

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

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


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

2007-03-13 Thread Andrew Dunstan

Magnus Hagander wrote:

On Mon, Mar 12, 2007 at 08:20:53PM -0500, Andrew Dunstan wrote:
  

Gregory Stark wrote:


Tom Lane [EMAIL PROTECTED] writes:

  

[EMAIL PROTECTED] (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

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


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

2007-03-12 Thread Tom Lane
[EMAIL PROTECTED] (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

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


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

2007-03-12 Thread Gregory Stark
Tom Lane [EMAIL PROTECTED] writes:

 [EMAIL PROTECTED] (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

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


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

2007-03-12 Thread Andrew Dunstan
Gregory Stark wrote:
 Tom Lane [EMAIL PROTECTED] writes:

 [EMAIL PROTECTED] (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


---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


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

2007-03-12 Thread Tom Lane
Gregory Stark [EMAIL PROTECTED] 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

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

   http://archives.postgresql.org