Add GUC_REPORT to server_encoding, integer_datetimes - Mailing list pgsql-patches

From Oliver Jowett
Subject Add GUC_REPORT to server_encoding, integer_datetimes
Date
Msg-id 411C37CF.7010000@opencloud.com
Whole thread Raw
Responses Re: Add GUC_REPORT to server_encoding, integer_datetimes  (Oliver Jowett <oliver@opencloud.com>)
Re: Add GUC_REPORT to server_encoding, integer_datetimes  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Add GUC_REPORT to server_encoding, integer_datetimes  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches
This adds GUC_REPORT to server_encoding and integer_datetimes so they
are reported in the V3 protocol startup packet. Also some related doc
updates.

Rationale:

1) server_encoding is useful to allow clients to detect bad
server/client encoding pairs. The one that bites JDBC regularly is
client_encoding = UNICODE with server_encoding = SQL_ASCII. I'd prefer
for the server to reject that combination entirely, but failing that
clients can implement such a policy themselves by inspecting
server_encoding when establishing a connection.

2) integer_datetimes affects the binary representation of date/time
types. A client that wants to use binary parameters or resultsets that
involve those types needs to know the value of this setting before
dealing with the binary data.

In both cases, it's good to have it in the startup packet to avoid an
extra round-trip on connection establishment.

Any chance that this can go into 8.0?

-O
? GNUmakefile
? config.log
? config.status
? src/Makefile.global
? src/include/pg_config.h
? src/include/stamp-h
Index: doc/src/sgml/libpq.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/libpq.sgml,v
retrieving revision 1.158
diff -u -c -r1.158 libpq.sgml
*** doc/src/sgml/libpq.sgml    11 Aug 2004 18:06:00 -0000    1.158
--- doc/src/sgml/libpq.sgml    13 Aug 2004 03:29:45 -0000
***************
*** 854,864 ****

  <para>
  Parameters reported as of the current release include
! <literal>server_version</> (cannot change after startup);
! <literal>client_encoding</>,
  <literal>is_superuser</>,
! <literal>session_authorization</literal>, and
! <literal>DateStyle</>.
  </para>

  <para>
--- 854,866 ----

  <para>
  Parameters reported as of the current release include
! <xref linkend="guc-server-version">,
! <xref linkend="guc-server-encoding">,
! <xref linkend="guc-client-encoding">,
  <literal>is_superuser</>,
! <literal>session_authorization</>,
! <xref linkend="guc-datestyle">, and
! <xref linkend="guc-integer-datetimes">.
  </para>

  <para>
Index: doc/src/sgml/protocol.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/protocol.sgml,v
retrieving revision 1.52
diff -u -c -r1.52 protocol.sgml
*** doc/src/sgml/protocol.sgml    11 Jun 2004 01:08:33 -0000    1.52
--- doc/src/sgml/protocol.sgml    13 Aug 2004 03:29:46 -0000
***************
*** 1046,1057 ****
     <para>
      At present there is a hard-wired set of parameters for which
      ParameterStatus will be generated: they are
!     <literal>server_version</> (a pseudo-parameter that cannot change after
!     startup);
!     <literal>client_encoding</>,
      <literal>is_superuser</>,
!     <literal>session_authorization</literal>, and
!     <literal>DateStyle</>.
      This set might change in the future, or even become configurable.
      Accordingly, a frontend should simply ignore ParameterStatus for
      parameters that it does not understand or care about.
--- 1046,1058 ----
     <para>
      At present there is a hard-wired set of parameters for which
      ParameterStatus will be generated: they are
!     <xref linkend="guc-server-version">,
!     <xref linkend="guc-server-encoding">,
!     <xref linkend="guc-client-encoding">,
      <literal>is_superuser</>,
!     <literal>session_authorization</>,
!     <xref linkend="guc-datestyle">, and
!     <xref linkend="guc-integer-datetimes">.
      This set might change in the future, or even become configurable.
      Accordingly, a frontend should simply ignore ParameterStatus for
      parameters that it does not understand or care about.
Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.276
diff -u -c -r1.276 runtime.sgml
*** doc/src/sgml/runtime.sgml    12 Aug 2004 19:03:17 -0000    1.276
--- doc/src/sgml/runtime.sgml    13 Aug 2004 03:29:46 -0000
***************
*** 2674,2681 ****

       <variablelist>

!      <varlistentry id="guc-datestyle" xreflabel="datestyle">
!       <term><varname>datestyle</varname> (<type>string</type>)</term>
        <indexterm><primary>date style</></>
        <listitem>
         <para>
--- 2674,2681 ----

       <variablelist>

!      <varlistentry id="guc-datestyle" xreflabel="DateStyle">
!       <term><varname>DateStyle</varname> (<type>string</type>)</term>
        <indexterm><primary>date style</></>
        <listitem>
         <para>
***************
*** 2747,2752 ****
--- 2747,2763 ----
        </listitem>
       </varlistentry>

+      <varlistentry id="guc-server-encoding" xreflabel="server_encoding">
+       <term><varname>server_encoding</varname> (<type>string</type>)</term>
+       <indexterm><primary>character set</></>
+       <listitem>
+        <para>
+         This parameter shows the database encoding (character set).
+         It is determined when the database is created, and is read-only.
+        </para>
+       </listitem>
+      </varlistentry>
+
       <varlistentry id="guc-client-encoding" xreflabel="client_encoding">
        <term><varname>client_encoding</varname> (<type>string</type>)</term>
        <indexterm><primary>character set</></>
***************
*** 3105,3110 ****
--- 3116,3131 ----

      <variablelist>

+      <varlistentry id="guc-server-version" xreflabel="server_version">
+       <term><varname>server_version</varname> (<type>string</type>)</term>
+       <listitem>
+        <para>
+         Shows the version number of the server. It is determined by the
+         value of <literal>PG_VERSION</> when building the server.
+        </para>
+       </listitem>
+      </varlistentry>
+
       <varlistentry id="guc-block-size" xreflabel="block_size">
        <term><varname>block_size</varname> (<type>integer</type>)</term>
        <listitem>
Index: src/backend/utils/misc/guc.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v
retrieving revision 1.231
diff -u -c -r1.231 guc.c
*** src/backend/utils/misc/guc.c    11 Aug 2004 21:10:37 -0000    1.231
--- src/backend/utils/misc/guc.c    13 Aug 2004 03:29:47 -0000
***************
*** 828,834 ****
          {"integer_datetimes", PGC_INTERNAL, COMPILE_OPTIONS,
              gettext_noop("Datetimes are integer based"),
              NULL,
!             GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
          },
          &integer_datetimes,
  #ifdef HAVE_INT64_TIMESTAMP
--- 828,834 ----
          {"integer_datetimes", PGC_INTERNAL, COMPILE_OPTIONS,
              gettext_noop("Datetimes are integer based"),
              NULL,
!             GUC_REPORT | GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
          },
          &integer_datetimes,
  #ifdef HAVE_INT64_TIMESTAMP
***************
*** 1624,1630 ****
          {"server_encoding", PGC_INTERNAL, CLIENT_CONN_LOCALE,
              gettext_noop("Sets the server (database) character set encoding."),
              NULL,
!             GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
          },
          &server_encoding_string,
          "SQL_ASCII", NULL, NULL
--- 1624,1630 ----
          {"server_encoding", PGC_INTERNAL, CLIENT_CONN_LOCALE,
              gettext_noop("Sets the server (database) character set encoding."),
              NULL,
!             GUC_REPORT | GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
          },
          &server_encoding_string,
          "SQL_ASCII", NULL, NULL

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [pgsql-hackers-win32] PITR on Win32 - Archive and Restore
Next
From: Bruce Momjian
Date:
Subject: Re: Minor BEFORE DELETE trigger fix