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)
Attachments:
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]http://developer.postgresql.org/pgdocs/postgres/index.html 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 } } [, ...] ) ] statementIt 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 } } [, ...] ) ] statementIt 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:
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:
- 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?
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
Attachments:
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
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
Attachments:
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
* 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
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