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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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. +

Attachment Content-Type Size
unknown_filename text/plain 27.9 KB

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2006-03-21 00:04:40 Re: Additional current timestamp values
Previous Message Bruce Momjian 2006-03-20 23:53:20 Re: Additional current timestamp values