Re: Exporting PGINTERVALSTYLE prevents access to older server versions
От | Tom Lane |
---|---|
Тема | Re: Exporting PGINTERVALSTYLE prevents access to older server versions |
Дата | |
Msg-id | 25980.1227624177@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Exporting PGINTERVALSTYLE prevents access to older server versions (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Exporting PGINTERVALSTYLE prevents access to older server versions
|
Список | 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 по дате отправления: