Re: Exporting PGINTERVALSTYLE prevents access to older server versions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Exporting PGINTERVALSTYLE prevents access to older server versions
Date
Msg-id 25980.1227624177@sss.pgh.pa.us
Whole thread Raw
In response to Re: Exporting PGINTERVALSTYLE prevents access to older server versions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Exporting PGINTERVALSTYLE prevents access to older server versions  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
I wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> (What is the use case for this variable anyway?  Is it there just 
>> because PGDATESTYLE was there previously?)

> Pretty much.  I'd be fine with taking it out entirely.

Actually ... I started to take this out and replace

*** pgsql/src/test/regress/pg_regress.c.orig     Tue Nov 25 09:18:16 2008
--- pgsql/src/test/regress/pg_regress.c  Tue Nov 25 09:29:46 2008
***************
*** 716,722 ****        */       putenv("PGTZ=PST8PDT");       putenv("PGDATESTYLE=Postgres, MDY");
!       putenv("PGINTERVALSTYLE=postgres_verbose");        if (temp_install)       {
--- 716,722 ----        */       putenv("PGTZ=PST8PDT");       putenv("PGDATESTYLE=Postgres, MDY");
!       putenv("PGOPTIONS=--intervalstyle=postgres_verbose");        if (temp_install)       {

when it struck me that that's going to still cause pg_regress to fail to
connect to older servers, which I suppose is the case that prompted you
to complain originally.  So I guess the real question is what is the
use case for having pg_regress talk to older servers?

I looked at whether we could send the value conditionally, but this
doesn't really work because libpq sends this stuff in the startup
packet; it doesn't know the exact server version at that point.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: blatantly a bug in the documentation
Next
From: "Fujii Masao"
Date:
Subject: New trigger file in pg_standby to promote the standby to the primary