Thread: Exporting PGINTERVALSTYLE prevents access to older server versions

Exporting PGINTERVALSTYLE causes errors of the following kind when 
connecting to an older server version:

psql: FATAL:  unrecognized configuration parameter "intervalstyle"

Should the processing of this variable be made conditional upon the 
server version?

(What is the use case for this variable anyway?  Is it there just 
because PGDATESTYLE was there previously?)

Peter Eisentraut <peter_e@gmx.net> writes:
> Exporting PGINTERVALSTYLE causes errors of the following kind when 
> connecting to an older server version:

> psql: FATAL:  unrecognized configuration parameter "intervalstyle"

Ooops.

> (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.
        regards, tom lane

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

On Tuesday 25 November 2008 16:42:57 Tom Lane wrote:
> --- 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.

Yeah, I was trying to reproduce the misbehavior I experienced the other day.  
In fact now pg_regress just hung somehow, and I found these errors about 
intervalstyle in the server log.  This is probably the psql try-to-connect 
loop in pg_regress.

> So I guess the real question is what is the 
> use case for having pg_regress talk to older servers?

There is no use.  I was just thinking, why create a new environment variable 
when actually setting that variable would create all kinds of havoc for 
users.

The change above looks appropriate to me.

(Better yet IMO would be to put SET statements into the SQL files where 
necessary.  But that is different matter.)

Peter Eisentraut <peter_e@gmx.net> writes:
> On Tuesday 25 November 2008 16:42:57 Tom Lane wrote:
>> !       putenv("PGOPTIONS=--intervalstyle=postgres_verbose");

>> So I guess the real question is what is the 
>> use case for having pg_regress talk to older servers?

> There is no use.  I was just thinking, why create a new environment variable 
> when actually setting that variable would create all kinds of havoc for 
> users.

> The change above looks appropriate to me.

Actually, in view of regressplans.sh, we have to work a bit harder than
that in pg_regress.c ... but I still agree that there's no real value in
adding a variable to libpq itself.  Change committed.
        regards, tom lane