Re: [HACKERS] old warning in docs
On Sat, Feb 15, 2014 at 07:34:20PM -0500, Bruce Momjian wrote: On Sat, Feb 15, 2014 at 07:19:46PM -0500, Robert Haas wrote: On Thu, Feb 13, 2014 at 10:55 AM, Bruce Momjian br...@momjian.us wrote: I have created the attached patch which removes many of the pre-8.0 references, and trims some of the 8.1-8.3 references. There are probably some of these that should be kept, but it is easier to show you all the possibilities and we can trim down the removal list based on feedback. The changes to lobj.sgml seem pointless. I would also vote for keeping xindex.sgml as-is. The rest of the changes seem like improvements. OK, done. Updated patch attached. Patch applied. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] old warning in docs
On Thu, Feb 13, 2014 at 10:55 AM, Bruce Momjian br...@momjian.us wrote: I have created the attached patch which removes many of the pre-8.0 references, and trims some of the 8.1-8.3 references. There are probably some of these that should be kept, but it is easier to show you all the possibilities and we can trim down the removal list based on feedback. The changes to lobj.sgml seem pointless. I would also vote for keeping xindex.sgml as-is. The rest of the changes seem like improvements. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] old warning in docs
On Sat, Feb 15, 2014 at 07:19:46PM -0500, Robert Haas wrote: On Thu, Feb 13, 2014 at 10:55 AM, Bruce Momjian br...@momjian.us wrote: I have created the attached patch which removes many of the pre-8.0 references, and trims some of the 8.1-8.3 references. There are probably some of these that should be kept, but it is easier to show you all the possibilities and we can trim down the removal list based on feedback. The changes to lobj.sgml seem pointless. I would also vote for keeping xindex.sgml as-is. The rest of the changes seem like improvements. OK, done. Updated patch attached. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml new file mode 100644 index 30fd9bb..a5b74e6 *** a/doc/src/sgml/datatype.sgml --- b/doc/src/sgml/datatype.sgml *** NUMERIC *** 744,754 note para ! Prior to productnamePostgreSQL/productname 7.4, the precision in ! typefloat(replaceablep/replaceable)/type was taken to mean ! so many emphasisdecimal/ digits. This has been corrected to match the SQL ! standard, which specifies that the precision is measured in binary ! digits. The assumption that typereal/type and typedouble 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 --- 744,750 note para ! The assumption that typereal/type and typedouble 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 *** ALTER SEQUENCE replaceable class=param *** 844,859 /para /note - note - para - Prior to productnamePostgreSQL/productname 7.3, typeserial/type - implied literalUNIQUE/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 - para To insert the next value of the sequence into the typeserial/type column, specify that the typeserial/type --- 840,845 *** SELECT E'\\xDEADBEEF'; *** 1602,1609 The SQL standard requires that writing just typetimestamp/type be equivalent to typetimestamp without time zone/type, and productnamePostgreSQL/productname honors that ! behavior. (Releases prior to 7.3 treated it as typetimestamp ! with time zone/type.) typetimestamptz/type is accepted as an abbreviation for typetimestamp with time zone/type; this is a productnamePostgreSQL/productname extension. /para --- 1588,1594 The SQL standard requires that writing just typetimestamp/type be equivalent to typetimestamp without time zone/type, and productnamePostgreSQL/productname honors that ! behavior. typetimestamptz/type is accepted as an abbreviation for typetimestamp with time zone/type; this is a productnamePostgreSQL/productname extension. /para diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml new file mode 100644 index bae2e97..8ace8bd *** a/doc/src/sgml/ddl.sgml --- b/doc/src/sgml/ddl.sgml *** CREATE TABLE circles ( *** 1106,1114 within a single transaction. In practice this limit is not a problem mdash; note that the limit is on the number of acronymSQL/acronym commands, not the number of rows processed. ! Also, as of productnamePostgreSQL/productname 8.3, only commands ! that actually modify the database contents will consume a command ! identifier. /para /sect1 --- 1106,1113 within a single transaction. In practice this limit is not a problem mdash; note that the limit is on the number of acronymSQL/acronym commands, not the number of rows processed. ! Also, only commands that actually modify the database contents will ! consume a command identifier. /para /sect1 *** REVOKE CREATE ON SCHEMA public FROM PUBL *** 1873,1883 /para para ! In productnamePostgreSQL/productname versions before 7.3, ! table names beginning with literalpg_/ 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
Re: [HACKERS] old warning in docs
On Mon, Oct 7, 2013 at 08:43:27AM -0700, David Fetter wrote: On Mon, Oct 07, 2013 at 07:51:44AM -0400, Andrew Dunstan wrote: Given that we have not supported releases older than 8.3 for quite a while, do we need to keep this in extend.sgml any longer? caution para Changing varnamePG_CONFIG/varname only works when building against productnamePostgreSQL/productname 8.3 or later. With older releases it does not work to set it to anything except literalpg_config/; you must alter your varnamePATH/ to select the installation to build against. /para /caution I say bin it. That reminds me. There are probably a lot of places in the docs that refer to versions of PostgreSQL a good bit older than 8.3. Will grep and patch as I get the time. I have created the attached patch which removes many of the pre-8.0 references, and trims some of the 8.1-8.3 references. There are probably some of these that should be kept, but it is easier to show you all the possibilities and we can trim down the removal list based on feedback. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml new file mode 100644 index 30fd9bb..a5b74e6 *** a/doc/src/sgml/datatype.sgml --- b/doc/src/sgml/datatype.sgml *** NUMERIC *** 744,754 note para ! Prior to productnamePostgreSQL/productname 7.4, the precision in ! typefloat(replaceablep/replaceable)/type was taken to mean ! so many emphasisdecimal/ digits. This has been corrected to match the SQL ! standard, which specifies that the precision is measured in binary ! digits. The assumption that typereal/type and typedouble 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 --- 744,750 note para ! The assumption that typereal/type and typedouble 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 *** ALTER SEQUENCE replaceable class=param *** 844,859 /para /note - note - para - Prior to productnamePostgreSQL/productname 7.3, typeserial/type - implied literalUNIQUE/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 - para To insert the next value of the sequence into the typeserial/type column, specify that the typeserial/type --- 840,845 *** SELECT E'\\xDEADBEEF'; *** 1602,1609 The SQL standard requires that writing just typetimestamp/type be equivalent to typetimestamp without time zone/type, and productnamePostgreSQL/productname honors that ! behavior. (Releases prior to 7.3 treated it as typetimestamp ! with time zone/type.) typetimestamptz/type is accepted as an abbreviation for typetimestamp with time zone/type; this is a productnamePostgreSQL/productname extension. /para --- 1588,1594 The SQL standard requires that writing just typetimestamp/type be equivalent to typetimestamp without time zone/type, and productnamePostgreSQL/productname honors that ! behavior. typetimestamptz/type is accepted as an abbreviation for typetimestamp with time zone/type; this is a productnamePostgreSQL/productname extension. /para diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml new file mode 100644 index bae2e97..8ace8bd *** a/doc/src/sgml/ddl.sgml --- b/doc/src/sgml/ddl.sgml *** CREATE TABLE circles ( *** 1106,1114 within a single transaction. In practice this limit is not a problem mdash; note that the limit is on the number of acronymSQL/acronym commands, not the number of rows processed. ! Also, as of productnamePostgreSQL/productname 8.3, only commands ! that actually modify the database contents will consume a command ! identifier. /para /sect1 --- 1106,1113 within a single transaction. In practice this limit is not a problem mdash; note that the limit is on the number of acronymSQL/acronym commands, not the number of rows processed. ! Also, only commands that actually modify the database contents will ! consume a command identifier. /para /sect1 *** REVOKE CREATE ON SCHEMA public FROM PUBL *** 1873,1883 /para para ! In
Re: [HACKERS] old warning in docs
On Mon, Oct 7, 2013 at 7:51 AM, Andrew Dunstan andrew.duns...@pgexperts.com wrote: Given that we have not supported releases older than 8.3 for quite a while, do we need to keep this in extend.sgml any longer? +1 for removing that (but only in master, not the back-branches). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] old warning in docs
On Oct 8, 2013 6:27 PM, Robert Haas robertmh...@gmail.com wrote: On Mon, Oct 7, 2013 at 7:51 AM, Andrew Dunstan andrew.duns...@pgexperts.com wrote: Given that we have not supported releases older than 8.3 for quite a while, do we need to keep this in extend.sgml any longer? +1 for removing that (but only in master, not the back-branches). +1, and definitely not in back branches. /Magnus
[HACKERS] old warning in docs
Given that we have not supported releases older than 8.3 for quite a while, do we need to keep this in extend.sgml any longer? caution para Changing varnamePG_CONFIG/varname only works when building against productnamePostgreSQL/productname 8.3 or later. With older releases it does not work to set it to anything except literalpg_config/; you must alter your varnamePATH/ to select the installation to build against. /para /caution cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] old warning in docs
On Mon, Oct 07, 2013 at 07:51:44AM -0400, Andrew Dunstan wrote: Given that we have not supported releases older than 8.3 for quite a while, do we need to keep this in extend.sgml any longer? caution para Changing varnamePG_CONFIG/varname only works when building against productnamePostgreSQL/productname 8.3 or later. With older releases it does not work to set it to anything except literalpg_config/; you must alter your varnamePATH/ to select the installation to build against. /para /caution I say bin it. That reminds me. There are probably a lot of places in the docs that refer to versions of PostgreSQL a good bit older than 8.3. Will grep and patch as I get the time. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
