Re: [HACKERS] Alpha 1 release notes
Peter, Attached is a new draft of the release notes. What I've done in this version is added more subsections and arranged stuff into groups by funcitonality area. I think this makes the notes vastly easier to scan; having 25 items generically under server wasn't helpful at all to find features and fixes. I'd like to do 2 more things today: a) rewrite a lot of the feature explanations more clearly so that most of our users can understand (and test) them. b) check against the gitlog to make sure we haven't missed anything. What's my deadline? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com .. -*- mode: rst -*- = Release 8.5alpha1 = .. last commit: Simplify and speed up man page installation Overview PostgreSQL alpha releases are snapshots of development code. They are intended to preview and test upcoming features and to provide the possibility for early feedback. They should not be used in production installations or active development projects. While the PostgreSQL code is continuously subject to a number of automated and manual tests, alpha releases might have serious bugs. Also features may be changed incompatibly or removed at any time during the development cycle. The development cycle of a PostgreSQL major release alternates between periods of development and periods of integration work, called commit fests, normally one month each. Alpha releases are planned to be produced at the end of every commit fest, thus every two months. Since the first commit fest starts within a month from the beginning of development altogether, early alpha releases are not indicative of the likely feature set of the final release. The release notes below highlight user visible changes and new features. There are normally numerous bug fixes and performance improvements in every new snapshot of PostgreSQL, and it would be too bulky to attempt to list them all. Note that many bug fixes are also backported to stable releases of PostgreSQL, and you should be using those if you are looking for bug-fix-only upgrades for your current installations. Migration - To upgrade from any release to an alpha release or from an alpha release to any other release will most likely require a dump/restore upgrade procedure. It may happen that this is not necessary in particular cases, but that is not verified beforehand. (The server will warn you in any case when a dump/restore is necessary if you attempt to use it with an old data directory.) Note, however, that the dump/restore upgrade procedure is expected to work for alpha releases, and problems in this area should be reported. Changes --- SQL Features - DROP IF EXISTS for columns and constraints - Allow parentheses around the query expression that follows a WITH clause. - INFORMATION_SCHEMA, a catalog of standard views of database objects, has been updated to the SQL:2008 ANSI/ISO standard. - Changed character_octet_length to more sensible values in INFORMATION_SCHEMA. - Simplify the forms foo true and foo false to foo = true and foo = false. - Allow * as parameter for FORCE QUOTE for COPY CSV - Support deferrable uniqueness constraints. Performance ~~~ - Make GEQO's planning deterministic by having it start from a predictable random number seed each time. - Rewrite GEQO's gimme_tree function so that it always finds a legal join sequence. Previously, it could have failed to produce a plan in some cases. - Tweak TOAST code so that columns marked with MAIN storage strategy are not forced out-of-line unless that is necessary to make the row fit on a page. Previously, they were forced out-of-line if needed to get the row down to the default target size (1/4th page). - EXPLAIN can now take generic options - EXPLAIN allows output of plans in XML or JSON format. - Added ALTER TABLE ... ALTER COLUMN ... SET STATISTICS DISTINCT Administration and Monitoring ~ - Added the ability to include the SQLSTATE error code of any error messages in the PostgreSQL activity log with the new log_line_prefix placeholder %e. - Fast shutdown stop should forcibly disconnect any active backends, even if a smart shutdown is already in progress. Backpatched to 8.3. Security - has_sequence_privilege() Built-In Functions ~~ - Fixed ancient bug in handling of to_char() modifier 'TH', when used with HH. - Use floor() not rint() when reducing precision of fractional seconds in timestamp_trunc, timestamptz_trunc, and interval_trunc() for the float-datetime case. - Support (scientific notation) in to_char(). pg_dump ~~~ - Fixed up --binary-upgrade option so that it behaves properly with inherited columns and check constraints. - Properly restore pg_largeobject.relfozenxid in binary upgrade mode. - Make pg_dump/pg_restore --clean options drop large objects too. - Modify parallel pg_restore
Re: [HACKERS] Alpha 1 release notes
Josh Berkus j...@agliodbs.com writes: Attached is a new draft of the release notes. I went over this quickly, and attach an updated version. This is updated to current CVS HEAD, and wordsmithed a little bit, and I removed some things that didn't seem worth documenting. In particular, the introduction claims that back-patched bug fixes won't be documented here, which I agree with (at least for minor fixes); but that policy wasn't being applied consistently. regards, tom lane .. -*- mode: rst -*- = Release 8.5alpha1 = .. last commit: Add prefix support for synonym dictionary Overview PostgreSQL alpha releases are snapshots of development code. They are intended to preview and test upcoming features and to provide the possibility for early feedback. They should not be used in production installations or active development projects. While the PostgreSQL code is continuously subject to a number of automated and manual tests, alpha releases might have serious bugs. Also features may be changed incompatibly or removed at any time during the development cycle. The development cycle of a PostgreSQL major release alternates between periods of development and periods of integration work, called commit fests, normally one month each. Alpha releases are planned to be produced at the end of every commit fest, thus every two months. Since the first commit fest starts within a month from the beginning of development altogether, early alpha releases are not indicative of the likely feature set of the final release. The release notes below highlight user visible changes and new features. There are normally numerous bug fixes and performance improvements in every new snapshot of PostgreSQL, and it would be too bulky to attempt to list them all. Note that many bug fixes are also backported to stable releases of PostgreSQL, and you should be using those if you are looking for bug-fix-only upgrades for your current installations. Migration - To upgrade from any release to an alpha release or from an alpha release to any other release will most likely require a dump/restore upgrade procedure. It may happen that this is not necessary in particular cases, but that is not verified beforehand. (The server will warn you in any case when a dump/restore is necessary if you attempt to use it with an old data directory.) Note, however, that the dump/restore upgrade procedure is expected to work for alpha releases, and problems in this area should be reported. Changes --- SQL Features - Add DROP IF EXISTS for columns and constraints. - INFORMATION_SCHEMA, a catalog of standard views of database objects, has been updated to the SQL:2008 ANSI/ISO standard. - Changed character_octet_length to more sensible values in INFORMATION_SCHEMA. - Allow * as parameter for FORCE QUOTE in COPY CSV (to select all columns). - Support deferrable uniqueness constraints. - Show the exact value being complained of in unique-constraint-violation error messages, including unique-index build failures. Performance ~~~ - Make GEQO's planning deterministic by having it start from a predictable random number seed each time. - Rewrite GEQO's gimme_tree function so that it always finds a legal join sequence. Previously, it could have failed to produce a plan in some cases. - Tweak TOAST code so that columns marked with MAIN storage strategy are not forced out-of-line unless that is necessary to make the row fit on a page. Previously, they were forced out-of-line if needed to get the row down to the default target size (1/4th page). - EXPLAIN can now take generic options; a COSTS OFF option is added. - EXPLAIN allows output of plans in XML or JSON format. - Add ALTER TABLE ... ALTER COLUMN ... SET STATISTICS DISTINCT. - Avoid per-send() system calls to manage SIGPIPE in libpq, if the platform provides either sockopt(SO_NOSIGPIPE) or the MSG_NOSIGNAL flag to send(). Administration and Monitoring ~ - Add the ability to include the SQLSTATE error code of any error messages in the PostgreSQL activity log with the new log_line_prefix placeholder %e. Built-In Functions ~~ - Add has_sequence_privilege() family of functions. - Fix ancient bug in handling of to_char() modifier 'TH', when used with HH. - Use floor() not rint() when reducing precision of fractional seconds in timestamp_trunc, timestamptz_trunc, and interval_trunc() for the float-datetime case. - Support (scientific notation) in to_char(). Datatypes ~ - New hex-string input and output format options for type BYTEA. Hex output format is enabled by default, which is an INCOMPATIBLE CHANGE. See the new bytea_output parameter if you need to restore compatibility. - Add prefix support for text search synonym dictionary. pg_dump ~~~ - Make pg_dump/pg_restore --clean options
Re: [HACKERS] Alpha 1 release notes
On 8/17/09 11:51 AM, Tom Lane wrote: I went over this quickly, and attach an updated version. This is updated to current CVS HEAD, and wordsmithed a little bit, and I removed some things that didn't seem worth documenting. In particular, the introduction claims that back-patched bug fixes won't be documented here, which I agree with (at least for minor fixes); but that policy wasn't being applied consistently. I thought the Windows memory thing was a back-patch? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- 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] Alpha 1 release notes
All, New version, incorporating Tom's changes and some additional reordering. Particularly, we seemed to vacillate between present and past tense for the patch descriptions. I have changed all to past tense. Also, should we be adding patch author names to these notes? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com .. -*- mode: rst -*- = Release 8.5alpha1 = .. last commit: Simplify and speed up man page installation Overview PostgreSQL alpha releases are snapshots of development code. They are intended to preview and test upcoming features and to provide the possibility for early feedback. They should not be used in production installations or active development projects. While the PostgreSQL code is continuously subject to a number of automated and manual tests, alpha releases might have serious bugs. Also features may be changed incompatibly or removed at any time during the development cycle. The development cycle of a PostgreSQL major release alternates between periods of development and periods of integration work, called commit fests, normally one month each. Alpha releases are planned to be produced at the end of every commit fest, thus every two months. Since the first commit fest starts within a month from the beginning of development altogether, early alpha releases are not indicative of the likely feature set of the final release. The release notes below highlight user visible changes and new features. There are normally numerous bug fixes and performance improvements in every new snapshot of PostgreSQL, and it would be too bulky to attempt to list them all. Note that many bug fixes are also backported to stable releases of PostgreSQL, and you should be using those if you are looking for bug-fix-only upgrades for your current installations. Migration - To upgrade from any release to an alpha release or from an alpha release to any other release will most likely require a dump/restore upgrade procedure. It may happen that this is not necessary in particular cases, but that is not verified beforehand. (The server will warn you in any case when a dump/restore is necessary if you attempt to use it with an old data directory.) Note, however, that the dump/restore upgrade procedure is expected to work for alpha releases, and problems in this area should be reported. Changes --- SQL Features - DROP COLUMN and DROP CONSTRAINT now support an IF EXISTS clause so that users can avoid fatal errors when running repeatable scripts. - UNIQUE constraints can now be DEFERRABLE. This is primarily useful for incremental updates of numerical keys, e.g. ID = ID + 1 - Allow parentheses around the query expression that follows a WITH clause. - INFORMATION_SCHEMA, a catalog of standard views of database objects, has been updated to the SQL:2008 ANSI/ISO standard. - Changed character_octet_length to more sensible values in INFORMATION_SCHEMA. - Allow * as parameter for FORCE QUOTE for COPY CSV, so that all columns will be quoted. Performance ~~~ - EXPLAIN allows output of plans in XML or JSON format for automated processing of explain plans by analysis or visualization tools. - EXPLAIN now supports the use of generic options in EXPLAIN ( option value, ... ) format, which will allows the creation of additional EXPLAIN options. - ALTER TABLE ... ALTER COLUMN ... SET STATISTICS DISTINCT allows users to manually tweak the number of distinct values estimated for a column, to fix cases where ANALYZE estimates are incorrect. - Make GEQO's planning deterministic by having it start from a predictable random number seed each time. - Rewrite GEQO's gimme_tree function so that it always finds a legal join sequence. Previously, it could have failed to produce a plan in some cases. - Tweak TOAST code so that columns marked with MAIN storage strategy are not forced out-of-line unless that is necessary to make the row fit on a page. Previously, they were forced out-of-line if needed to get the row down to the default target size (1/4th page). - Simplify the forms foo true and foo false to foo = true and foo = false during query optimization. - Avoid per-send() system calls to manage SIGPIPE in libpq, if the platform provides either sockopt(SO_NOSIGPIPE) or the MSG_NOSIGNAL flag to send(). Administration and Monitoring ~ - Added the ability to include the SQLSTATE error code of any error messages in the PostgreSQL activity log with the new log_line_prefix placeholder %e. - Show the exact value being complained of in unique-constraint-violation error messages, including unique-index build failures. Security - New has_sequence_privilege() functions allow you to check sequence privileges for a given ROLE. Built-In Functions ~~ - The to_char() formatting functions now supports (scientific
Re: [HACKERS] Alpha 1 release notes
Josh Berkus j...@agliodbs.com writes: On 8/17/09 11:51 AM, Tom Lane wrote: I went over this quickly, and attach an updated version. This is updated to current CVS HEAD, and wordsmithed a little bit, and I removed some things that didn't seem worth documenting. In particular, the introduction claims that back-patched bug fixes won't be documented here, which I agree with (at least for minor fixes); but that policy wasn't being applied consistently. I thought the Windows memory thing was a back-patch? It is, but it seems worth mentioning for testing purposes, since it's a portability issue. See prior discussion. regards, tom lane -- 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] Alpha 1 release notes
Josh Berkus j...@agliodbs.com writes: Particularly, we seemed to vacillate between present and past tense for the patch descriptions. I have changed all to past tense. Actually, present tense is our general style for the release notes, and I had carefully made them all present tense ;-). It doesn't appear to me that you've been consistent about it here anyway. regards, tom lane -- 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] Alpha 1 release notes
Tom, Actually, present tense is our general style for the release notes, and I had carefully made them all present tense ;-). It doesn't appear to me that you've been consistent about it here anyway. OK, switching back to present tense then. Does anyone else see anything missing? Also, does the ADD/DROP COLUMN plpgsql patch fix any cases other than RETURNS QUERY? I can't tell from the patch. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- 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] Alpha 1 release notes
Josh Berkus j...@agliodbs.com writes: Also, does the ADD/DROP COLUMN plpgsql patch fix any cases other than RETURNS QUERY? I can't tell from the patch. Yes, I believe it does, but hadn't bothered to work up any test cases. The places it touched in plpgsql are * returning a single composite value * returning a tuple from a trigger function * assignment to a record variable * RETURN QUERY I think that the trigger function case would usually work (since you'd generally be doing RETURN NEW or RETURN OLD which should have dead columns in the right places already) but the other two were probably just as problematic as RETURN QUERY. regards, tom lane -- 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] Alpha 1 release notes
On mån, 2009-08-17 at 10:39 -0700, Josh Berkus wrote: Peter, Attached is a new draft of the release notes. What I've done in this version is added more subsections and arranged stuff into groups by funcitonality area. I think this makes the notes vastly easier to scan; having 25 items generically under server wasn't helpful at all to find features and fixes. I'd like to do 2 more things today: a) rewrite a lot of the feature explanations more clearly so that most of our users can understand (and test) them. b) check against the gitlog to make sure we haven't missed anything. What's my deadline? When you're done, run the file through pandoc -f rst -t docbook and paste it into the release notes SGML source. (Maybe create a new file for 8.5 already.) -- 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] Alpha 1 release notes
Peter, Since I'd need to install haskell on my system before installing pandoc, I've attached my final edit of the RST file so that I don't hold things up. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com .. -*- mode: rst -*- = Release 8.5alpha1 = Overview PostgreSQL alpha releases are snapshots of development code. They are intended to preview and test upcoming features and to provide the possibility for early feedback. They should not be used in production installations or active development projects. While the PostgreSQL code is continuously subject to a number of automated and manual tests, alpha releases might have serious bugs. Also features may be changed incompatibly or removed at any time during the development cycle. The development cycle of a PostgreSQL major release alternates between periods of development and periods of integration work, called commit fests, normally one month each. Alpha releases are planned to be produced at the end of every commit fest, thus every two months. Since the first commit fest starts within a month from the beginning of development altogether, early alpha releases are not indicative of the likely feature set of the final release. The release notes below highlight user visible changes and new features. There are normally numerous bug fixes and performance improvements in every new snapshot of PostgreSQL, and it would be too bulky to attempt to list them all. Note that many bug fixes are also backported to stable releases of PostgreSQL, and you should be using those if you are looking for bug-fix-only upgrades for your current installations. Migration - To upgrade from any release to an alpha release or from an alpha release to any other release will most likely require a dump/restore upgrade procedure. It may happen that this is not necessary in particular cases, but that is not verified beforehand. (The server will warn you in any case when a dump/restore is necessary if you attempt to use it with an old data directory.) Note, however, that the dump/restore upgrade procedure is expected to work for alpha releases, and problems in this area should be reported. Changes --- SQL Features - DROP COLUMN and DROP CONSTRAINT now support an IF EXISTS clause so that users can avoid fatal errors when running repeatable scripts. - UNIQUE constraints can now be DEFERRABLE. This is primarily useful for incremental updates of numerical keys, e.g. ID = ID + 1 - Allows parentheses around the query expression that follows a WITH clause. - INFORMATION_SCHEMA, a catalog of standard views of database objects, has been updated to the SQL:2008 ANSI/ISO standard. - Changes character_octet_length to more sensible values in INFORMATION_SCHEMA. - Allow * as parameter for FORCE QUOTE for COPY CSV, so that all columns will be quoted. Performance ~~~ - EXPLAIN allows output of plans in XML or JSON format for automated processing of explain plans by analysis or visualization tools. - EXPLAIN now supports the use of generic options in EXPLAIN ( option value, ... ) format, which permits the creation of additional EXPLAIN options. - ALTER TABLE ... ALTER COLUMN ... SET STATISTICS DISTINCT allows users to manually tweak the number of distinct values estimated for a column, to fix cases where ANALYZE estimates are incorrect. - Makes GEQO's planning deterministic by having it start from a predictable random number seed each time. - Rewrite GEQO's gimme_tree function so that it always finds a legal join sequence. Previously, it could have failed to produce a plan in some cases. - Tweak TOAST code so that columns marked with MAIN storage strategy are not forced out-of-line unless that is necessary to make the row fit on a page. Previously, they were forced out-of-line if needed to get the row down to the default target size (1/4th page). - Simplify the forms foo true and foo false to foo = false and foo = true during query optimization. - Avoid per-send() system calls to manage SIGPIPE in libpq, if the platform provides either sockopt(SO_NOSIGPIPE) or the MSG_NOSIGNAL flag to send(). - Reserve the shared memory region during backend startup on Windows, so that memory allocated by starting third party DLLs doesn't end up conflicting with it. Hopefully this solves the long-time issue with could not reattach to shared memory errors on Win32. Administration and Monitoring ~ - Add the ability to include the SQLSTATE error code of any error messages in the PostgreSQL activity log with the new log_line_prefix placeholder %e. - Show the exact value being complained of in unique-constraint-violation error messages, including unique-index build failures. Security - New has_sequence_privilege() functions allow you to check sequence privileges for a given ROLE. Built-In Functions
Re: [HACKERS] Alpha 1 release notes
On mån, 2009-08-17 at 14:29 -0700, Josh Berkus wrote: Since I'd need to install haskell on my system before installing pandoc, I've attached my final edit of the RST file so that I don't hold things up. committed that -- 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] Alpha 1 release notes
Hi, Josh Berkus j...@agliodbs.com writes: Will do. Teaching myself RST now I've been doing a lot of RST editing before, and found it pretty straightforward. Except for default table handling, where ascii-art maintenance is a pain, or you have to use extended tools, like emacs table mode and such. Or use list-table and rejoy :) http://docutils.sourceforge.net/docs/ref/rst/directives.html#list-table Regards, -- dim -- 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] Alpha 1 release notes
within source code, build options there is: - Reserve the shared memory region during backend startup on Windows, so that memory allocated by starting third party DLLs doesn't end up conflicting with it. Hopefully this solves the long-time issue with could not reattach to shared memory errors on Win32. I suggest that it should also be pointed out that this fix will be backported to 8.3 and 8.4 (as much as I followed the ML); similiar to the information at - Fast shutdown stop should forcibly disconnect any active backends, even if a smart shutdown is already in progress. Backpatched to 8.3. best wishes Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - LASIK good, steroids bad?
Re: [HACKERS] Alpha 1 release notes
Dimitri Fontaine wrote: Hi, Josh Berkus j...@agliodbs.com writes: Will do. Teaching myself RST now I've been doing a lot of RST editing before, and found it pretty straightforward. Except for default table handling, where ascii-art maintenance is a pain, or you have to use extended tools, like emacs table mode and such. Or use list-table and rejoy :) http://docutils.sourceforge.net/docs/ref/rst/directives.html#list-table Yeah, table handling in RST is pretty silly, particularly when you have to escape some character in a cell. I wonder if this format can be converted to SGML DocBook automatically. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] Alpha 1 release notes
On Thursday 13 August 2009 17:07:38 Alvaro Herrera wrote: I wonder if this format can be converted to SGML DocBook automatically. Yes, that's why I used it. -- 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] Alpha 1 release notes
Massa, Harald Armin c...@ghum.de writes: within source code, build options there is: - Reserve the shared memory region during backend startup on Windows, so that memory allocated by starting third party DLLs doesn't end up conflicting with it. Hopefully this solves the long-time issue with could not reattach to shared memory errors on Win32. I suggest that it should also be pointed out that this fix will be backported to 8.3 and 8.4 (as much as I followed the ML); Normally, bug fixes that have been back-patched wouldn't be mentioned at all in a new major release's release notes. The implied base that we are comparing to in major-release notes is the end of the prior branch's updates. I'm not sure if this case should be an exception, or if we should have a different general rule for alpha releases. We'd like to get more testing on that fix, so I think it is reasonable to mention it for alpha1 --- but is that an exception specific to this bug fix, or does it indicate we want to handle bug fixes differently in general within alpha release notes? In any case, it is not the function of the alpha release notes to discuss changes in earlier release branches. The reason the commit log points out the back-patch is to make it easier to extract the information when we prepare release notes for the back-branch updates. regards, tom lane -- 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] Alpha 1 release notes
Tom Lane wrote: In any case, it is not the function of the alpha release notes to discuss changes in earlier release branches. The reason the commit log points out the back-patch is to make it easier to extract the information when we prepare release notes for the back-branch updates. Hmm, isn't it enough to use cvs2cl --follow branch? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] Alpha 1 release notes
Alvaro Herrera alvhe...@commandprompt.com writes: Tom Lane wrote: In any case, it is not the function of the alpha release notes to discuss changes in earlier release branches. The reason the commit log points out the back-patch is to make it easier to extract the information when we prepare release notes for the back-branch updates. Hmm, isn't it enough to use cvs2cl --follow branch? Yeah, cvs will certainly tell you the same information, which is why I frequently don't bother mentioning the point at all in commit messages. I think the most useful reason for mentioning the branch(es) in a commit message is to explain why a particular patch goes back so far and no farther. regards, tom lane -- 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] Alpha 1 release notes
Tom Lane wrote: Massa, Harald Armin c...@ghum.de writes: within source code, build options there is: - Reserve the shared memory region during backend startup on Windows, so that memory allocated by starting third party DLLs doesn't end up conflicting with it. Hopefully this solves the long-time issue with could not reattach to shared memory errors on Win32. I suggest that it should also be pointed out that this fix will be backported to 8.3 and 8.4 (as much as I followed the ML); Normally, bug fixes that have been back-patched wouldn't be mentioned at all in a new major release's release notes. The implied base that we are comparing to in major-release notes is the end of the prior branch's updates. I'm not sure if this case should be an exception, or if we should have a different general rule for alpha releases. We'd like to get more testing on that fix, so I think it is reasonable to mention it for alpha1 --- but is that an exception specific to this bug fix, or does it indicate we want to handle bug fixes differently in general within alpha release notes? In any case, it is not the function of the alpha release notes to discuss changes in earlier release branches. The reason the commit log points out the back-patch is to make it easier to extract the information when we prepare release notes for the back-branch updates. FYI, tools/pgcvslog -d removes backbranch commits automatically. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] Alpha 1 release notes
On Wednesday 12 August 2009 03:34:22 Josh Berkus wrote: On 8/11/09 3:27 PM, Peter Eisentraut wrote: OK, since there was no clear consensus or volunteer for preparing release notes for alpha 1, I have started something. Let me know what you think. Actually, the consensus was that Bruce was not going to share, so Robert and I didn't want to bother trying to compose formal release notes. Can we put your text file somewhere we can collaborate on it? I started a page on the wiki, but would gladly use your version as the seed instead: http://wiki.postgresql.org/wiki/85AlphaFeatures Can you export DocBook from that? -- 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] Alpha 1 release notes
Can you export DocBook from that? Not without writing some custom perl code, no. Should we stick your release notes on git somewhere? I'd like to expand the and add a couple of things. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- 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] Alpha 1 release notes
On Wednesday 12 August 2009 19:27:06 Josh Berkus wrote: Can you export DocBook from that? Not without writing some custom perl code, no. Should we stick your release notes on git somewhere? I'd like to expand the and add a couple of things. I say just take the file and edit it. -- 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] Alpha 1 release notes
On 8/12/09 11:13 AM, Peter Eisentraut wrote: On Wednesday 12 August 2009 19:27:06 Josh Berkus wrote: Can you export DocBook from that? Not without writing some custom perl code, no. Should we stick your release notes on git somewhere? I'd like to expand the and add a couple of things. I say just take the file and edit it. Will do. Teaching myself RST now -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Alpha 1 release notes
OK, since there was no clear consensus or volunteer for preparing release notes for alpha 1, I have started something. Let me know what you think. (reStructuredText, if you want to play around) .. -*- mode: rst -*- = Release 8.5alpha1 = .. last commit: Simplify and speed up man page installation Overview PostgreSQL alpha releases are snapshots of development code. They are intended to preview and test upcoming features and to provide the possibility for early feedback. They should not be used in production installations or active development projects. While the PostgreSQL code is continuously subject to a number of automated and manual tests, alpha releases might have serious bugs. Also features may be changed incompatibly or removed at any time during the development cycle. The development cycle of a PostgreSQL major release alternates between periods of development and periods of integration work, called commit fests, normally one month each. Alpha releases are planned to be produced at the end of every commit fest, thus every two months. Since the first commit fest starts within a month from the beginning of development altogether, early alpha releases are not indicative of the likely feature set of the final release. The release notes below highlight user visible changes and new features. There are normally numerous bug fixes and performance improvements in every new snapshot of PostgreSQL, and it would be too bulky to attempt to list them all. Note that many bug fixes are also backported to stable releases of PostgreSQL, and you should be using those if you are looking for bug-fix-only upgrades for your current installations. Migration - To upgrade from any release to an alpha release or from an alpha release to any other release will most likely require a dump/restore upgrade procedure. It may happen that this is not necessary in particular cases, but that is not verified beforehand. (The server will warn you in any case when a dump/restore is necessary if you attempt to use it with an old data directory.) Note, however, that the dump/restore upgrade procedure is expected to work for alpha releases, and problems in this area should be reported. Changes --- Server ~~ - Added log_line_prefix placeholder %e to contain the current SQL state - Allow parentheses around the query expression that follows a WITH clause. - Fixed ancient bug in handling of to_char modifier 'TH', when used with HH. - Use floor() not rint() when reducing precision of fractional seconds in timestamp_trunc, timestamptz_trunc, and interval_trunc() for the float-datetime case. - More sensible values for character_octet_length column in information schema. - Information schema updated to SQL:2008 - Backend header files are now safe to use with C++. - Make GEQO's planning deterministic by having it start from a predictable random number seed each time. - Rewrite GEQO's gimme_tree function so that it always finds a legal join sequence. Previously, it could have failed to produce a plan in some cases. - Simplify the forms foo true and foo false to foo = true and foo = false. - DROP IF EXISTS for columns and constraints - Tweak TOAST code so that columns marked with MAIN storage strategy are not forced out-of-line unless that is necessary to make the row fit on a page. Previously, they were forced out-of-line if needed to get the row down to the default target size (1/4th page). - EXPLAIN can now take generic options - EXPLAIN allows output of plans in XML or JSON format. - Support (scientific notation) in to_char(). - Allow * as parameter for FORCE QUOTE for COPY CSV - Support deferrable uniqueness constraints. - Added ALTER TABLE ... ALTER COLUMN ... SET STATISTICS DISTINCT - has_sequence_privilege() - New hex-string input and output for type BYTEA. - Fast shutdown stop should forcibly disconnect any active backends, even if a smart shutdown is already in progress. Backpatched to 8.3. pg_dump ~~~ - Fixed up --binary-upgrade option so that it behaves properly with inherited columns and check constraints. - Properly restore pg_largeobject.relfozenxid in binary upgrade mode. - Make pg_dump/pg_restore --clean options drop large objects too. - Modify parallel pg_restore logic to avoid potential O(N^2) slowdown in extreme cases. psql - Have \\d show child tables that inherit from the specified parent - Show definition of index columns in \\d on index ecpg - Added STRING datatype for Informix compatibility mode. Procedural Languages - Improve plpgsql's ability to cope with rowtypes containing dropped columns, Contrib ~~~ - Multi-threaded version of pgbench - Adds the ability to retrieve async notifications using dblink, via the addition of the function dblink_get_notify(). - Add matchorig, matchsynonyms, and keepsynonyms options to
Re: [HACKERS] Alpha 1 release notes
A Dimecres, 12 d'agost de 2009, Peter Eisentraut va escriure: OK, since there was no clear consensus or volunteer for preparing release notes for alpha 1, I have started something. Let me know what you think. (reStructuredText, if you want to play around) Maybe I'd be interesting to add development docs URL [1] so testers can easily find the syntax of new features, or given that they'll be downloading the alpha tarball they should use that documentation? [1] http://developer.postgresql.org/pgdocs/postgres/index.html -- Albert Cervera i Areny http://www.NaN-tic.com Mòbil: +34 669 40 40 18 -- 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] Alpha 1 release notes
If I didn't read this email I would still be trying to figure out how
to use the explain XML patch. Thanks Albert.
I found the syntax for the explain xml format to be quite difficult to
understand at first, it would be nice to give an example or two, ie:
EXPLAIN (ANALYZE, FORMAT XML) SELECT * FROM foo WHERE i = 4;
The thing that caused me the most trouble was that the , wasn't very
noticeable sitting near the end of this line:
EXPLAIN [ ( { ANALYZE boolean | VERBOSE boolean | COSTS boolean |
FORMAT { TEXT | XML | JSON } } [, ...] ) ] statement
It may just be me, but I read that as the comma being optional, not
mandatory in circumstances where you want to specify more then one
option.
Nonetheless, an additional example with multiple options would sure
help.
Thanks.
On Wed, 12 Aug 2009 01:08:54 +0200
Albert Cervera i Areny alb...@nan-tic.com wrote:
A Dimecres, 12 d'agost de 2009, Peter Eisentraut va escriure:
OK, since there was no clear consensus or volunteer for preparing
release notes for alpha 1, I have started something. Let me know
what you think.
(reStructuredText, if you want to play around)
Maybe I'd be interesting to add development docs URL [1] so testers
can easily find the syntax of new features, or given that they'll be
downloading the alpha tarball they should use that documentation?
[1] http://developer.postgresql.org/pgdocs/postgres/index.html
--
Mike
--
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] Alpha 1 release notes
Mike wrote:
The thing that caused me the most trouble was that the , wasn't very
noticeable sitting near the end of this line:
EXPLAIN [ ( { ANALYZE boolean | VERBOSE boolean | COSTS boolean |
FORMAT { TEXT | XML | JSON } } [, ...] ) ] statement
It may just be me, but I read that as the comma being optional, not
mandatory in circumstances where you want to specify more then one
option.
It is you -- what's optional is having more than one option, but as soon
as you have a second one, the comma is mandatory.
I agree some examples would be useful.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
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] Alpha 1 release notes
On 8/11/09 3:27 PM, Peter Eisentraut wrote: OK, since there was no clear consensus or volunteer for preparing release notes for alpha 1, I have started something. Let me know what you think. Actually, the consensus was that Bruce was not going to share, so Robert and I didn't want to bother trying to compose formal release notes. Can we put your text file somewhere we can collaborate on it? I started a page on the wiki, but would gladly use your version as the seed instead: http://wiki.postgresql.org/wiki/85AlphaFeatures -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- 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] Alpha 1 release notes
On Tue, Aug 11, 2009 at 8:32 PM, Alvaro
Herreraalvhe...@commandprompt.com wrote:
Mike wrote:
The thing that caused me the most trouble was that the , wasn't very
noticeable sitting near the end of this line:
EXPLAIN [ ( { ANALYZE boolean | VERBOSE boolean | COSTS boolean |
FORMAT { TEXT | XML | JSON } } [, ...] ) ] statement
It may just be me, but I read that as the comma being optional, not
mandatory in circumstances where you want to specify more then one
option.
It is you -- what's optional is having more than one option, but as soon
as you have a second one, the comma is mandatory.
I agree some examples would be useful.
Hmm, I thought we had some examples in there, but now that I look we
only have an example for COSTS OFF, not for FORMAT. That does seem
like an oversight.
...Robert
--
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] Alpha 1 release notes
Robert Haas robertmh...@gmail.com writes: Hmm, I thought we had some examples in there, but now that I look we only have an example for COSTS OFF, not for FORMAT. That does seem like an oversight. I thought about adding one when I committed the patch, but concluded that there was no point until the output format stabilized. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
