Thread: Removal of pre-7.4 documentation items
With us supporting only PG >=8.0, I think we can remove some mentions of pre-7.4 releases. The attached patch show my proposed removals. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/datatype.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v retrieving revision 1.242 diff -c -c -r1.242 datatype.sgml *** doc/src/sgml/datatype.sgml 17 Feb 2010 04:19:37 -0000 1.242 --- doc/src/sgml/datatype.sgml 23 Feb 2010 00:16:14 -0000 *************** *** 715,725 **** <note> <para> ! Prior to <productname>PostgreSQL</productname> 7.4, the precision in ! <type>float(<replaceable>p</replaceable>)</type> was taken to mean ! so many <emphasis>decimal</> digits. This has been corrected to match the SQL ! standard, which specifies that the precision is measured in binary ! digits. The assumption that <type>real</type> and <type>double precision</type> have exactly 24 and 53 bits in the mantissa respectively is correct for IEEE-standard floating point implementations. On non-IEEE platforms it might be off a little, but --- 715,721 ---- <note> <para> ! The assumption that <type>real</type> and <type>double precision</type> have exactly 24 and 53 bits in the mantissa respectively is correct for IEEE-standard floating point implementations. On non-IEEE platforms it might be off a little, but *************** *** 795,805 **** <note> <para> ! Prior to <productname>PostgreSQL</productname> 7.3, <type>serial</type> ! implied <literal>UNIQUE</literal>. This is no longer automatic. If ! you wish a serial column to have a unique constraint or be a ! primary key, it must now be specified, just like ! any other data type. </para> </note> --- 791,799 ---- <note> <para> ! If you wish a serial column to have a unique constraint or be ! a primary key, it must be specified, just like any other data ! type. </para> </note> *************** *** 1521,1534 **** </tgroup> </table> - <note> - <para> - Prior to <productname>PostgreSQL</productname> 7.3, writing just - <type>timestamp</type> was equivalent to <type>timestamp with - time zone</type>. This was changed for SQL compliance. - </para> - </note> - <para> <type>time</type>, <type>timestamp</type>, and <type>interval</type> accept an optional precision value --- 1515,1520 ---- Index: doc/src/sgml/ddl.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/ddl.sgml,v retrieving revision 1.88 diff -c -c -r1.88 ddl.sgml *** doc/src/sgml/ddl.sgml 23 Oct 2009 05:24:52 -0000 1.88 --- doc/src/sgml/ddl.sgml 23 Feb 2010 00:16:14 -0000 *************** *** 1795,1812 **** </para> <para> ! In <productname>PostgreSQL</productname> versions before 7.3, ! table names beginning with <literal>pg_</> were reserved. This is ! no longer true: you can create such a table name if you wish, in ! any non-system schema. However, it's best to continue to avoid ! such names, to ensure that you won't suffer a conflict if some ! future version defines a system table named the same as your ! table. (With the default search path, an unqualified reference to ! your table name would then be resolved as the system table instead.) ! System tables will continue to follow the convention of having ! names beginning with <literal>pg_</>, so that they will not ! conflict with unqualified user-table names so long as users avoid ! the <literal>pg_</> prefix. </para> </sect2> --- 1795,1806 ---- </para> <para> ! It is best to avoid table names beginning with <literal>pg_</> ! because they might someday conflict with system catalogs of the ! same name. (<productname>PostgreSQL</productname> system catalog ! table names always start with <literal>pg_</>). Of course, table ! names can always be schema-qualified to avoid conflicting with ! system catalog table names. </para> </sect2> *************** *** 3040,3054 **** </para> </note> - <note> - <para> - Foreign key constraint dependencies and serial column dependencies - from <productname>PostgreSQL</productname> versions prior to 7.3 - are <emphasis>not</emphasis> maintained or created during the - upgrade process. All other dependency types will be properly - created during an upgrade from a pre-7.3 database. - </para> - </note> </sect1> </chapter> --- 3034,3039 ---- Index: doc/src/sgml/libpq.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v retrieving revision 1.300 diff -c -c -r1.300 libpq.sgml *** doc/src/sgml/libpq.sgml 17 Feb 2010 04:19:37 -0000 1.300 --- doc/src/sgml/libpq.sgml 23 Feb 2010 00:16:14 -0000 *************** *** 1203,1216 **** has been sent to the server and not yet completed. </para> - <caution> - <para> - <function>PQtransactionStatus</> will give incorrect results when using - a <productname>PostgreSQL</> 7.3 server that has the parameter <literal>autocommit</> - set to off. The server-side autocommit feature has been - deprecated and does not exist in later server versions. - </para> - </caution> </listitem> </varlistentry> --- 1203,1208 ---- Index: doc/src/sgml/protocol.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/protocol.sgml,v retrieving revision 1.83 diff -c -c -r1.83 protocol.sgml *** doc/src/sgml/protocol.sgml 22 Feb 2010 18:12:04 -0000 1.83 --- doc/src/sgml/protocol.sgml 23 Feb 2010 00:16:15 -0000 *************** *** 165,172 **** <para> Data of a particular data type might be transmitted in any of several ! different <firstterm>formats</>. As of <productname>PostgreSQL</> 7.4 ! the only supported formats are <quote>text</> and <quote>binary</>, but the protocol makes provision for future extensions. The desired format for any value is specified by a <firstterm>format code</>. Clients can specify a format code for each transmitted parameter value --- 165,172 ---- <para> Data of a particular data type might be transmitted in any of several ! different <firstterm>formats</>. ! The only supported formats are <quote>text</> and <quote>binary</>, but the protocol makes provision for future extensions. The desired format for any value is specified by a <firstterm>format code</>. Clients can specify a format code for each transmitted parameter value Index: doc/src/sgml/rules.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/rules.sgml,v retrieving revision 1.53 diff -c -c -r1.53 rules.sgml *** doc/src/sgml/rules.sgml 5 Nov 2009 23:24:22 -0000 1.53 --- doc/src/sgml/rules.sgml 23 Feb 2010 00:16:15 -0000 *************** *** 1828,1836 **** </listitem> </itemizedlist> - (This system was established in <productname>PostgreSQL</> 7.3. - In versions before that, the command status might show different - results when rules exist.) </para> <para> --- 1828,1833 ---- Index: doc/src/sgml/xindex.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v retrieving revision 1.64 diff -c -c -r1.64 xindex.sgml *** doc/src/sgml/xindex.sgml 7 Dec 2008 23:46:39 -0000 1.64 --- doc/src/sgml/xindex.sgml 23 Feb 2010 00:16:19 -0000 *************** *** 895,910 **** try to use these SQL features with the data type. </para> - <note> - <para> - In <productname>PostgreSQL</productname> versions before 7.4, - sorting and grouping operations would implicitly use operators named - <literal>=</>, <literal><</>, and <literal>></>. The new - behavior of relying on default operator classes avoids having to make - any assumption about the behavior of operators with particular names. - </para> - </note> - <para> Another important point is that an operator that appears in a hash operator family is a candidate for hash joins, --- 895,900 ----
Bruce Momjian wrote: > With us supporting only PG >=8.0, I think we can remove some mentions of > pre-7.4 releases. The attached patch show my proposed removals. Applied. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive, Christ can be your backup. +
On Mon, 2010-02-22 at 19:18 -0500, Bruce Momjian wrote: > With us supporting only PG >=8.0, Really? Since when? -- Devrim GÜNDÜZ, RHCE PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
Attachment
2010/2/24 Devrim GÜNDÜZ <devrim@gunduz.org>: > On Mon, 2010-02-22 at 19:18 -0500, Bruce Momjian wrote: >> With us supporting only PG >=8.0, > > Really? Since when? http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy And we're not likely to release 9.0 before then :( -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
2010/2/24 Magnus Hagander <magnus@hagander.net>: > 2010/2/24 Devrim GÜNDÜZ <devrim@gunduz.org>: >> On Mon, 2010-02-22 at 19:18 -0500, Bruce Momjian wrote: >>> With us supporting only PG >=8.0, >> >> Really? Since when? > > http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy > > And we're not likely to release 9.0 before then :( In that case, it should be >= 8.1. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com PG East Conference: http://www.enterprisedb.com/community/nav-pg-east-2010.do
Dave Page wrote: > 2010/2/24 Magnus Hagander <magnus@hagander.net>: > > 2010/2/24 Devrim G?ND?Z <devrim@gunduz.org>: > >> On Mon, 2010-02-22 at 19:18 -0500, Bruce Momjian wrote: > >>> With us supporting only PG >=8.0, > >> > >> Really? Since when? > > > > http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy > > > > And we're not likely to release 9.0 before then :( > > In that case, it should be >= 8.1. I am sure there are some people lagging behind so I kept >=7.4 info. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive, Christ can be your backup. +
bruce wrote: > Dave Page wrote: > > 2010/2/24 Magnus Hagander <magnus@hagander.net>: > > > 2010/2/24 Devrim G?ND?Z <devrim@gunduz.org>: > > >> On Mon, 2010-02-22 at 19:18 -0500, Bruce Momjian wrote: > > >>> With us supporting only PG >=8.0, > > >> > > >> Really? Since when? > > > > > > http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy > > > > > > And we're not likely to release 9.0 before then :( > > > > In that case, it should be >= 8.1. > > I am sure there are some people lagging behind so I kept >=7.4 info. Also, another reason to keep >= 7.4 is people might be porting old, unused application code from older releases to current ones. Here are the appropriate removals for the reference manual pages. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/ref/copy.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/ref/copy.sgml,v retrieving revision 1.95 diff -c -c -r1.95 copy.sgml *** doc/src/sgml/ref/copy.sgml 23 Feb 2010 21:38:35 -0000 1.95 --- doc/src/sgml/ref/copy.sgml 24 Feb 2010 14:48:33 -0000 *************** *** 629,641 **** a file trailer. Headers and data are in network byte order. </para> - <note> - <para> - <productname>PostgreSQL</productname> releases before 7.4 used a - different binary file format. - </para> - </note> - <refsect3> <title>File Header</title> --- 629,634 ---- Index: doc/src/sgml/ref/create_cast.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/ref/create_cast.sgml,v retrieving revision 1.32 diff -c -c -r1.32 create_cast.sgml *** doc/src/sgml/ref/create_cast.sgml 19 Sep 2009 10:23:26 -0000 1.32 --- doc/src/sgml/ref/create_cast.sgml 24 Feb 2010 14:48:33 -0000 *************** *** 324,340 **** </para> <para> - Prior to <productname>PostgreSQL</> 7.3, every function that had - the same name as a data type, returned that data type, and took one - argument of a different type was automatically a cast function. - This convention has been abandoned in face of the introduction of - schemas and to be able to represent binary-coercible casts in the - system catalogs. The built-in cast functions still follow this naming - scheme, but they have to be shown as casts in the system catalog - <structname>pg_cast</> as well. - </para> - - <para> While not required, it is recommended that you continue to follow this old convention of naming cast implementation functions after the target data type. Many users are used to being able to cast data types using a --- 324,329 ---- Index: doc/src/sgml/ref/create_language.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/ref/create_language.sgml,v retrieving revision 1.49 diff -c -c -r1.49 create_language.sgml *** doc/src/sgml/ref/create_language.sgml 23 Feb 2010 22:51:42 -0000 1.49 --- doc/src/sgml/ref/create_language.sgml 24 Feb 2010 14:48:33 -0000 *************** *** 264,278 **** the installation.) </para> - <para> - In <productname>PostgreSQL</productname> versions before 7.3, it was - necessary to declare handler functions as returning the placeholder - type <type>opaque</>, rather than <type>language_handler</>. - To support loading - of old dump files, <command>CREATE LANGUAGE</> will accept a function - declared as returning <type>opaque</>, but it will issue a notice and - change the function's declared return type to <type>language_handler</>. - </para> </refsect1> <refsect1 id="sql-createlanguage-examples"> --- 264,269 ---- Index: doc/src/sgml/ref/create_trigger.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/ref/create_trigger.sgml,v retrieving revision 1.52 diff -c -c -r1.52 create_trigger.sgml *** doc/src/sgml/ref/create_trigger.sgml 20 Nov 2009 20:38:09 -0000 1.52 --- doc/src/sgml/ref/create_trigger.sgml 24 Feb 2010 14:48:33 -0000 *************** *** 272,285 **** rows. </para> - <para> - In <productname>PostgreSQL</productname> versions before 7.3, it was - necessary to declare trigger functions as returning the placeholder - type <type>opaque</>, rather than <type>trigger</>. To support loading - of old dump files, <command>CREATE TRIGGER</> will accept a function - declared as returning <type>opaque</>, but it will issue a notice and - change the function's declared return type to <type>trigger</>. - </para> </refsect1> <refsect1 id="SQL-CREATETRIGGER-examples"> --- 272,277 ---- Index: doc/src/sgml/ref/create_type.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/ref/create_type.sgml,v retrieving revision 1.80 diff -c -c -r1.80 create_type.sgml *** doc/src/sgml/ref/create_type.sgml 26 Dec 2009 16:55:21 -0000 1.80 --- doc/src/sgml/ref/create_type.sgml 24 Feb 2010 14:48:33 -0000 *************** *** 663,680 **** function is written in C. </para> - <para> - In <productname>PostgreSQL</productname> versions before 7.3, it - was customary to avoid creating a shell type at all, by replacing the - functions' forward references to the type name with the placeholder - pseudotype <type>opaque</>. The <type>cstring</> arguments and - results also had to be declared as <type>opaque</> before 7.3. To - support loading of old dump files, <command>CREATE TYPE</> will - accept I/O functions declared using <type>opaque</>, but it will issue - a notice and change the function declarations to use the correct - types. - </para> - </refsect1> <refsect1> --- 663,668 ---- Index: doc/src/sgml/ref/pg_config-ref.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/ref/pg_config-ref.sgml,v retrieving revision 1.28 diff -c -c -r1.28 pg_config-ref.sgml *** doc/src/sgml/ref/pg_config-ref.sgml 18 Feb 2008 14:51:48 -0000 1.28 --- doc/src/sgml/ref/pg_config-ref.sgml 24 Feb 2010 14:48:33 -0000 *************** *** 275,289 **** <title>Notes</title> <para> - The option <option>--includedir-server</option> was new in - <productname>PostgreSQL</> 7.2. In prior releases, the server include files were - installed in the same location as the client headers, which could - be queried with the option <option>--includedir</option>. To make your - package handle both cases, try the newer option first and test the - exit status to see whether it succeeded. - </para> - - <para> The options <option>--docdir</option>, <option>--pkgincludedir</option>, <option>--localedir</option>, <option>--mandir</option>, <option>--sharedir</option>, <option>--sysconfdir</option>, --- 275,280 ---- *************** *** 294,304 **** The option <option>--htmldir</option> is new in <productname>PostgreSQL</> 8.4. </para> - <para> - In releases prior to <productname>PostgreSQL</> 7.1, before - <command>pg_config</command> came to be, a method for finding the - equivalent configuration information did not exist. - </para> </refsect1> --- 285,290 ---- Index: doc/src/sgml/ref/psql-ref.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v retrieving revision 1.239 diff -c -c -r1.239 psql-ref.sgml *** doc/src/sgml/ref/psql-ref.sgml 19 Feb 2010 14:36:45 -0000 1.239 --- doc/src/sgml/ref/psql-ref.sgml 24 Feb 2010 14:48:37 -0000 *************** *** 3149,3155 **** server is of a newer version than <application>psql</> itself. However, backslash commands of the <literal>\d</> family should work with servers of versions back to 7.4, though not necessarily with servers ! newer than <application>psql</> itself. </para> </listitem> --- 3149,3155 ---- server is of a newer version than <application>psql</> itself. However, backslash commands of the <literal>\d</> family should work with servers of versions back to 7.4, though not necessarily with servers ! newer than <application>psql</> itself. </para> </listitem> Index: doc/src/sgml/ref/reindex.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/ref/reindex.sgml,v retrieving revision 1.39 diff -c -c -r1.39 reindex.sgml *** doc/src/sgml/ref/reindex.sgml 7 Feb 2010 20:48:09 -0000 1.39 --- doc/src/sgml/ref/reindex.sgml 24 Feb 2010 14:48:37 -0000 *************** *** 226,237 **** factor. The old behavior is available as <command>REINDEX SYSTEM</>. </para> - <para> - Prior to <productname>PostgreSQL</productname> 7.4, <command>REINDEX - TABLE</> did not automatically process TOAST tables, and so those had - to be reindexed by separate commands. This is still possible, but - redundant. - </para> </refsect1> <refsect1> --- 226,231 ----