Thread: 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)
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
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 <albert@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
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 Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
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
On Tue, Aug 11, 2009 at 8:32 PM, Alvaro
Herrera<alvherre@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
Robert Haas <robertmhaas@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
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?
> 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
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.
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
Hi, Josh Berkus <josh@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
within source code, build options there is:<br /><br /><pre>- Reserve the shared memory region during backend startup onWindows,<br /> so that memory allocated by starting third party DLLs doesn't end up<br /> conflicting with it. Hopefullythis solves the long-time issue with<br /> "could not reattach to shared memory" errors on Win32.<br /></pre><br/>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 followedthe ML); similiar to the information at <br /><pre>- Fast shutdown stop should forcibly disconnect any active backends,<br/> even if a smart shutdown is already in progress. Backpatched to 8.3.<br /></pre> <br />best wishes <br /><br/>Harald <br /><br clear="all" /><br />-- <br />GHUM Harald Massa<br /> persuadere et programmare<br />Harald ArminMassa<br />Spielberger Straße 49<br />70435 Stuttgart<br />0173/9409607<br />no fx, no carrier pigeon <br />-<br />LASIKgood, steroids bad?<br />
Dimitri Fontaine wrote: > > Hi, > > Josh Berkus <josh@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 Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
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.
"Massa, Harald Armin" <chef@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
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 Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera <alvherre@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
Tom Lane wrote: > "Massa, Harald Armin" <chef@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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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
Attachment
Josh Berkus <josh@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 EEEE (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 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
~~~~
- Add STRING datatype for Informix compatibility mode.
Procedural Languages
~~~~~~~~~~~~~~~~~~~~
- Improve plpgsql's ability to cope with rowtypes containing dropped
columns,
- Improve error context reporting in plpython.
- Greatly expand the regression testing for plpython.
Contrib
~~~~~~~
- Support multi-threading in pgbench.
- Add the ability to retrieve async notifications using dblink, via
the addition of the function dblink_get_notify().
- Add matchorig, matchsynonyms, and keepsynonyms options to
contrib/dict_xsyn.
Development
~~~~~~~~~~~
- Names that conflict with C++ reserved words have been renamed,
making backend header files now safe to use with C++ libraries.
- Add man pages for SPI functions.
Source code, build options
~~~~~~~~~~~~~~~~~~~~~~~~~~
- Upgrade to Autoconf 2.63
(not relevant to users of distribution tarballs).
- Minimum version of Flex is now 2.5.31, to support reentrant scanners
(not relevant to users of distribution tarballs).
- Documentation build rules have been improved. The generated
documentation files are now shipped "loose", not in sub-tarballs.
- New toolchain to generate man pages. From now on, the man pages
will be current in every release.
- 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.
- Make the core scanner re-entrant, along with additional fixes that
will let it be used directly by plpgsql.
- Fix backend startup to not depend on the flat-file copy of pg_database.
This is a first step towards eliminating the flat files altogether.
- Add s_lock support for SuperH architecture (not well tested).
- Code-coverage testing support now extends to the entire source tree, not
only src/backend/.
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
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
Attachment
Josh Berkus <josh@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
Josh Berkus <josh@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
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
Josh Berkus <josh@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*
assignmentto 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
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.)
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
Attachment
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