7.4 compatibility question
Hi,
Now that DEFAULT 'now' will not work in PostgreSQL 7.4, will DEFAULT
'infinity' and DEFAULT '-infinity' and the like stop working as well?
What is the workaround for those defaults?
Chris
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
Now that DEFAULT 'now' will not work in PostgreSQL 7.4, will DEFAULT
'infinity' and DEFAULT '-infinity' and the like stop working as well?
No, because those values don't change over time. The issue here is when
exactly does the default value get evaluated...
regards, tom lane
Now that DEFAULT 'now' will not work in PostgreSQL 7.4, will DEFAULT
'infinity' and DEFAULT '-infinity' and the like stop working as well?No, because those values don't change over time. The issue here is when
exactly does the default value get evaluated...
Ah, of course - but what about 'yesterday' and 'tomorrow' - these should
also be mentioned in the release notes.
Chris
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
Now that DEFAULT 'now' will not work in PostgreSQL 7.4, will DEFAULT
'infinity' and DEFAULT '-infinity' and the like stop working as well?No, because those values don't change over time. The issue here is when
exactly does the default value get evaluated...
Ah, of course - but what about 'yesterday' and 'tomorrow' - these should
also be mentioned in the release notes.
Good point ... not that I think anyone is actually using such a default
in the field, but the behavior did change ...
regards, tom lane
Tom Lane wrote:
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
Now that DEFAULT 'now' will not work in PostgreSQL 7.4, will DEFAULT
'infinity' and DEFAULT '-infinity' and the like stop working as well?No, because those values don't change over time. The issue here is when
exactly does the default value get evaluated...Ah, of course - but what about 'yesterday' and 'tomorrow' - these should
also be mentioned in the release notes.Good point ... not that I think anyone is actually using such a default
in the field, but the behavior did change ...
It would be pretty strange to use those as a default --- I am not
inclined to mention it in the release notes --- we don't mention every
change, only significant ones.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073It would be pretty strange to use those as a default --- I am not
inclined to mention it in the release notes --- we don't mention every
change, only significant ones.
Personally, I think that's a fairly silly policy! How does it hurt us
to mention it and you just know that someone, somewhere, is doing it...
Chris
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Tom Lane wrote:
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
Ah, of course - but what about 'yesterday' and 'tomorrow' - these should
also be mentioned in the release notes.Good point ... not that I think anyone is actually using such a default
in the field, but the behavior did change ...
It would be pretty strange to use those as a default --- I am not
inclined to mention it in the release notes --- we don't mention every
change, only significant ones.
A moment's further thought reveals 'today' as another potentially broken
default value, which seems more likely to be used in practice than
'yesterday' or 'tomorrow'. I'm too beat to go digging for other legal
inputs, but there may be some...
regards, tom lane
On Wed, 2003-10-22 at 00:41, Christopher Kings-Lynne wrote:
It would be pretty strange to use those as a default --- I am not
inclined to mention it in the release notes --- we don't mention every
change, only significant ones.Personally, I think that's a fairly silly policy!
I agree -- documenting possible areas of incompatibility is important,
and I would prefer that we err on the side of mentioning too much,
rather than too little.
-Neil
A moment's further thought reveals 'today' as another potentially broken
default value, which seems more likely to be used in practice than
'yesterday' or 'tomorrow'. I'm too beat to go digging for other legal
inputs, but there may be some...
Ah, I didn't mention that one because I thought it was obvious and had
already been mentioned :P
Chris
Christopher Kings-Lynne wrote:
It would be pretty strange to use those as a default --- I am not
inclined to mention it in the release notes --- we don't mention every
change, only significant ones.Personally, I think that's a fairly silly policy! How does it hurt us
to mention it and you just know that someone, somewhere, is doing it...
The release notes are already 550 lines --- adding the mention of
something almost no one uses doesn't make sense --- if we did that, the
list might be 1000 lines and more unreadable. Same logic goes for the
list of changes --- I only mention user-visible changes, in most cases.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Neil Conway wrote:
On Wed, 2003-10-22 at 00:41, Christopher Kings-Lynne wrote:
It would be pretty strange to use those as a default --- I am not
inclined to mention it in the release notes --- we don't mention every
change, only significant ones.Personally, I think that's a fairly silly policy!
I agree -- documenting possible areas of incompatibility is important,
and I would prefer that we err on the side of mentioning too much,
rather than too little.
Docs updated to include 'today':
<listitem><para> <literal>'now'</literal> will no longer work as a
column default; <function>now()</> or
<function>CURRENT_TIMESTAMP</> should be used instead</para></listitem>
<listitem><para> <literal>'today'</literal> will no longer work as
a column default; <function>CURRENT_DATE</>
should be used instead</para></listitem>
As far as yesterday/tomorrow, I think anyone using that will realize
that if 'today' doesn't work, those will not either. Sure, I like to be
complete too, but at a certain point it becomes overload and people
can't process it. Part of the reason the release notes are read is
because they are _readable_, or as readable was we can make +300
changes.
Do you think I include every user-visible change in the release notes?
It would be 2-3x longer, and probably not more useful.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073On Wed, 2003-10-22 at 01:08, Bruce Momjian wrote:
Do you think I include every user-visible change in the release notes?
It would be 2-3x longer, and probably not more useful.
Part of the reason the release notes are read is
because they are _readable_
On the contrary, I think we could do a lot to make the release notes
more readable, while at the same time providing more information to
users.
We're really serving two different audiences with the release notes.
Some people are just interested in the highlights of the release, so
that they are up to date on the latest new PostgreSQL functionality. For
these people, I think the existing "highlights of the release" section
at the top of the release notes is sufficient, although it could
probably be made a less terse.
The second audience is the people who are really interested in exactly
what has changed between the new release of PostgreSQL and the previous
release series. It is important that we make it easy for an admin
planning a PostgreSQL upgrade at a fairly large site to be able to see
what changes in PostgreSQL have been made, and what changes will be
necessary in their own applications. This audience is served fairly well
by the present release notes, but I think we could do better. The
backward-incompatibility section could definitely be improved, and the
whole process of summarizing the CVS logs after the fact is sure to lose
information. Furthermore, many of the release note entries are so brief
that it's difficult, even for someone familiar with PostgreSQL, to tell
exactly what they mean. Sometimes the entry doesn't even bother to
specify exactly what has been changed. Using complete sentences, where
warranted, and describing complex or important changes with a full
paragraph of text would be a good idea, IMHO. I've appended a few
examples of less-than-optimal entries to this mail.
So I think we could make the release notes more useful if we provided a
bit more detail in each entry, and documented changes more extensively.
We could also make better use of SGML, for example by adding <xref>s to
the release notes where applicable. I think we also need to *really*
maintain the release notes incrementally during 7.5 development, rather
than having Bruce summarize the CVS logs at the end. IMHO, every patch
that makes a significant change should update the release notes, when
the patch is applied.
Anyway, those are my thoughts on how to improve the release notes. I've
been meaning to get this off my chest for a while, so thanks for the
chance :-)
Comments are welcome.
-Neil
Here are a few examples of less-than-optimal entries I noticed while
browsing the release notes recently:
This HISTORY entry from 7.4 doesn't really tell anyone anything:
* Multiple pg_dump fixes, including tar format and large objects
Or take this entry -- I can basically decipher what it means, but it
takes a fair degree of difficulty:
* Disallow literal carriage return as a data value,
backslash-carriage-return and \r are still allowed (Bruce)
Or this entry, which once again conveys little useful information, to me
at least:
* Improve \d display (Christopher)
On Wednesday 22 October 2003 07:37, Neil Conway wrote:
The second audience is the people who are really interested in exactly
what has changed between the new release of PostgreSQL and the previous
release series. It is important that we make it easy for an admin
planning a PostgreSQL upgrade at a fairly large site to be able to see
what changes in PostgreSQL have been made, and what changes will be
necessary in their own applications.
Something I was pondering the other day was whether a pg_compat_chk utility
would be practical/desirable. You run it against your existing database /
schema dump and it prints a set of warnings:
Old version = 7.2.1
New version = 7.4.0
Warning: schema support introduced (v7.3)
all objects will be placed in the default schema
Failure: DEFAULT 'now' not supported (v7.4)
table1.column2
table2.column3
Notice: timestamp now holds milliseconds by default (v7.3)
tableX.whatever
My main concern would be that a 90% solution might be worse than nothing at
all.
Incidentally, this is not idle speculation, but something I might well have
time to stick in gborg during the 7.5 devt cycle.
--
Richard Huxton
Archonet Ltd
Neil Conway wrote:
On Wed, 2003-10-22 at 01:08, Bruce Momjian wrote:
Do you think I include every user-visible change in the release notes?
It would be 2-3x longer, and probably not more useful.Part of the reason the release notes are read is
because they are _readable_On the contrary, I think we could do a lot to make the release notes
more readable, while at the same time providing more information to
users.Here are a few examples of less-than-optimal entries I noticed while
browsing the release notes recently:This HISTORY entry from 7.4 doesn't really tell anyone anything:
* Multiple pg_dump fixes, including tar format and large objects
I agree it would be nice to use more xrefs in the release notes.
What happens when you go into more detail is that it comes even more
confusing --- in most cases we fixed some obscure flag combination or
something, and explaining that is even harder than just saying we fixed
some rare pg_dump failure cases. The people who reported the problem
have already gotten their fix, and in most cases, they are the only ones
to have ever tried that combination --- documenting that doesn't really
add much, at least for me and I would assume 99% of our users. We could
go for 99.9% of our users, but that makes things harder to filter for
the other 99%.
Please do a test --- do a cvs log of the bin/pg_dump directory and see
if I missed anything significant in the release notes.
If you start listing obscure changes, the significant ones don't really
stand out anymore. You could add a 'obscure changes' section, but I
think once you create the list and read it, it will look pretty obscure.
Or take this entry -- I can basically decipher what it means, but it
takes a fair degree of difficulty:* Disallow literal carriage return as a data value,
backslash-carriage-return and \r are still allowed (Bruce)
OK, please improve the wording.
Or this entry, which once again conveys little useful information, to me
at least:* Improve \d display (Christopher)
There were a huge number of \d display improvements --- do \d in 7.4 and
you will see them --- I don't see much value in saying, "Rules now
display as ...", or "defaults now have more parens".
I have always encouraged people to improve the existing notes. I don't
pretend to use the perfect wording --- please send in improvements.
As far as incrementally updating the release notes --- lots of our work
is incremental, meaning we fix X, then add Y, and Z, and the resulting
change is one release note entry (psql \d display improvements, for
example). Documenting them separately just leads to a mess of entries
that we have to consolidate at the end anyway.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce Momjian <pgman@candle.pha.pa.us> writes:
As far as incrementally updating the release notes --- lots of our work
is incremental, meaning we fix X, then add Y, and Z, and the resulting
change is one release note entry (psql \d display improvements, for
example). Documenting them separately just leads to a mess of entries
that we have to consolidate at the end anyway.
We do already have a practice of adding notes about significant changes
to release.sgml as they are made. That's relatively new though, and I
dunno if it's helped Bruce prepare the finished release notes or not.
Bruce, did you use those notes at all this time?
regards, tom lane
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
As far as incrementally updating the release notes --- lots of our work
is incremental, meaning we fix X, then add Y, and Z, and the resulting
change is one release note entry (psql \d display improvements, for
example). Documenting them separately just leads to a mess of entries
that we have to consolidate at the end anyway.We do already have a practice of adding notes about significant changes
to release.sgml as they are made. That's relatively new though, and I
dunno if it's helped Bruce prepare the finished release notes or not.
Bruce, did you use those notes at all this time?
I checked them to make sure they were already included in my CVS notes,
and I might have used some of its wording if it was better than mine.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
We integrate PostgreSQL with our product, which we ship to the end user.
We do read the release notes, they are important to us.
They don't have to be excruciatingly long, they can't be
ridiculously short and cryptic.
You have to find the golden spot in the middle. Just treat us
the way you want to be treated + some extra allowance for ignorance.
Mike.
Show quoted text
Part of the reason the release notes are read is
because they are _readable_
Michael Brusser wrote:
We integrate PostgreSQL with our product, which we ship to the end user.
We do read the release notes, they are important to us.
They don't have to be excruciatingly long, they can't be
ridiculously short and cryptic.
You have to find the golden spot in the middle. Just treat us
the way you want to be treated + some extra allowance for ignorance.
The big question is whether the current release notes hit he right
balanced. Do they for you?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073On Wed, 2003-10-22 at 13:26, Tom Lane wrote:
We do already have a practice of adding notes about significant changes
to release.sgml as they are made. That's relatively new though, and I
dunno if it's helped Bruce prepare the finished release notes or not.
Right, we also did a pretty bad job of incrementally updating
release.sgml during the development cycle: only a small portion of all
the changes that we made actually got added to it. I think it would be a
good idea to try to be better at this during the 7.5 cycle. When 7.5
development begins, we should divide release.sgml into the relevant
sections (e.g. "libpq", "contrib", "performance", "highlights of the
release", etc.), and then keep it updated whenever a relevant change is
made.
IMHO that would be bother easier to maintain (see we need to write CVS
changelog entries anyway, and Bruce wouldn't need to spend as long
summarizing the changes at the end of the dev cycle), as well as
producing a better quality release notes -- but since Bruce is the one
actually doing the work, I'm content to leave this in his hands.
-Neil
Neil Conway wrote:
On Wed, 2003-10-22 at 13:26, Tom Lane wrote:
We do already have a practice of adding notes about significant changes
to release.sgml as they are made. That's relatively new though, and I
dunno if it's helped Bruce prepare the finished release notes or not.Right, we also did a pretty bad job of incrementally updating
release.sgml during the development cycle: only a small portion of all
the changes that we made actually got added to it. I think it would be a
good idea to try to be better at this during the 7.5 cycle. When 7.5
development begins, we should divide release.sgml into the relevant
sections (e.g. "libpq", "contrib", "performance", "highlights of the
release", etc.), and then keep it updated whenever a relevant change is
made.IMHO that would be bother easier to maintain (see we need to write CVS
changelog entries anyway, and Bruce wouldn't need to spend as long
summarizing the changes at the end of the dev cycle), as well as
producing a better quality release notes -- but since Bruce is the one
actually doing the work, I'm content to leave this in his hands.
I find it easier to generate a list from raw CVS than to merge +500
entries into a consistent whole, and I never expect the maintained list
to be 100% accurate, so I have to do the CVS thing anyway.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
