Skip site navigation (1) Skip section navigation (2)

Re: Removal of backward-compatibility docs mentions

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Removal of backward-compatibility docs mentions
Date: 2006-03-20 23:54:13
Message-ID: 200603202354.k2KNsDM14270@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
I have made the modifications you suggested.  Any others?

---------------------------------------------------------------------------

Neil Conway wrote:
> [ Sorry for the two copies, Bruce: I forgot to CC the list previously ]
> 
> On Mon, 2006-03-20 at 13:57 -0500, Bruce Momjian wrote:
> > The attached patch removes or minimizes some documentation mentions of
> > backward compatibility for release 7.2 and earlier.
> 
> I don't think it's a net win to get rid of this text, as it describes
> useful alternatives to the GUC variable:
> 
> *** doc/src/sgml/config.sgml    10 Mar 2006 19:10:47 -0000      1.52
> --- doc/src/sgml/config.sgml    20 Mar 2006 18:40:44 -0000
> ***************
> *** 3789,3801 ****
>         <listitem>
>          <para>
>           This controls the inheritance semantics, in particular whether
> !         subtables are included by various commands by default. They
> were
> !         not included in versions prior to 7.1. If you need the old
> !         behavior you can set this variable to <literal>off</>, but in
> !         the long run you are encouraged to change your applications to
> !         use the <literal>ONLY</literal> key word to exclude subtables.
> !         See <xref linkend="ddl-inherit"> for more information about
> !         inheritance.
>          </para>
>         </listitem>
>        </varlistentry>
> --- 3789,3796 ----
>         <listitem>
>          <para>
>           This controls the inheritance semantics, in particular whether
> !         subtables are included by various commands by default. This
> was
> !         added for compatibility with releases prior to 7.1.
>          </para>
>         </listitem>
>        </varlistentry>
> 
> *** doc/src/sgml/libpq.sgml     10 Mar 2006 19:10:48 -0000      1.206
> --- doc/src/sgml/libpq.sgml     20 Mar 2006 18:41:05 -0000
> ***************
> *** 689,699 ****
>   functions described below to get
>   at the contents of <structname>PGconn</structname>.  Avoid directly
> referencing the fields of the
>   <structname>PGconn</> structure because they are subject to change in
> the future.
> - (Beginning in <productname>PostgreSQL</productname> release 6.4, the
> - definition of the <type>struct</type> behind <structname>PGconn</> is
> not even provided in <filename>libpq-fe.h</filename>.
> - If you have old code that accesses <structname>PGconn</structname>
> fields directly, you can keep using it
> - by including <filename>libpq-int.h</filename> too, but you are
> encouraged to fix the code
> - soon.)
>   </para>
>   </tip>
> 
> Removing the information about libpq-int.h but keeping the suggestion to
> "avoid directly referencing fields of the PGconn structure" doesn't seem
> consistent: the user *can't* directly reference fields without including
> libpq-int.h. So I think this hunk should be kept.
> 
> The second hunk modified in maintenance.sgml removes some useful
> information (ANALYZE collects rows by random sampling).
> 
> >From storage.sgml:
> 
> !  Since <productname>PostgreSQL</productname> uses a fixed page size
> (commonly
> ! 8Kb), and does not allow tuples to span multiple pages, so it's not
> possible to
> ! store very large field values directly.
> 
> That is poorly phrased ("Since ..., so it's not").
> 
> -Neil
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>        message can get through to the mailing list cleanly
> 

-- 
  Bruce Momjian   http://candle.pha.pa.us
  SRA OSS, Inc.   http://www.sraoss.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2006-03-21 00:04:40
Subject: Re: Additional current timestamp values
Previous:From: Bruce MomjianDate: 2006-03-20 23:53:20
Subject: Re: Additional current timestamp values

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group