Thread: Help me improve the 9.2 release announcement!

Folks,

Selena and I have started drafting a release annoucement for version
9.2.   It still needs quite a bit of polish before it's ready for
translation, but I'd like to make it final within a week.

We're going with a 2-part theme: Performance/Scalability, and JSON.
Among other things, this means leaving a major feature (Range Types) out
of the release announcement.  However, I couldn't find a way to make
range types fit with a general theme, *and* they are hard to explain to
reporters and analysts (despite the fact that this is the one 9.2
feature I personally am already using).

Stuff that needs help:

* The intro paragraph is flat and boring.  Needs jazzing up without
overloading the superlatives.
* The text on performance is largely a copy of what we already put in
the beta release.  Seems like we could have more here.
* Maybe the explanations of the new JSON features could be longer?  I'm
not sure.

I've thrown it up on the PostgreSQL wiki in order to enhance
collaboration.  If you can see ways to improve the text, please either
edit it or post your own version.  Just remember to annotate your edits!

https://wiki.postgresql.org/wiki/ReleaseAnnounce92

Oh, also, the text of the quotes is fixed.  I might get new quotes
before press time, but you can't edit what other people are saying.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

On Aug 3, 2012, at 8:23 PM, Josh Berkus wrote:

> We're going with a 2-part theme: Performance/Scalability, and JSON.
> Among other things, this means leaving a major feature (Range Types) out
> of the release announcement.   However, I couldn't find a way to make
> range types fit with a general theme, *and* they are hard to explain to
> reporters and analysts (despite the fact that this is the one 9.2
> feature I personally am already using).

I was planning to mention range types in a quote that I was going to submit.  I think they are too important to leave
out. In many ways, it would be better to promote the range type functionality  in this release than JSON as range types
supporttype extensions and have GiST indexing available.  The primary target of people using Postgres are still
developers,so we want them to be aware of what cool features are available. 

For instance, a way to describe ranges in a way that both developers + reporters could understand: "PostgreSQL now
supportsrange data types, which allow developers to quickly find overlapping series of data, useful for booking and
reservationsystems." 

The ability to stored formatted JSON in Postgres is great, but it is still limited in terms of how we can interact with
itcompared to some of the other DBs on the market.  Looking at the notes from the dev conf, it would be better to
activelypromote the JSON support on the 9.3 release as one of the key features, should a lot of those mentioned
featuresget into the release. 

Will take a crack at some language edits this evening.

Jonathan

Jonathan S. Katz, 06.08.2012 20:56:
>> We're going with a 2-part theme: Performance/Scalability, and
>> JSON. Among other things, this means leaving a major feature (Range
>> Types) out of the release announcement.   However, I couldn't find
>> a way to make range types fit with a general theme, *and* they are
>> hard to explain to reporters and analysts (despite the fact that
>> this is the one 9.2 feature I personally am already using).
>
> I was planning to mention range types in a quote that I was going to
> submit.  I think they are too important to leave out.  In many ways,
> it would be better to promote the range type functionality  in this
> release than JSON

I second that.

I too find the range types more important than a somewhat unfinished
JSON support (In my opinion it's missing indexing and access functions
to make it really usable)


> "PostgreSQL now supports range data types, which allow developers to
> quickly find overlapping series of data, useful for booking and
> reservation systems."

I like that.

Thomas Kellerer <spam_eater@gmx.net> wrote:

>> I was planning to mention range types in a quote that I was going to
>> submit.  I think they are too important to leave out.  In many ways,
>> it would be better to promote the range type functionality  in this
>> release than JSON
>
> I second that.
>
> I too find the range types more important than a somewhat unfinished
> JSON support (In my opinion it's missing indexing and access functions
> to make it really usable)

+1

>
>
>> "PostgreSQL now supports range data types, which allow developers to
>> quickly find overlapping series of data, useful for booking and
>> reservation systems."
>
> I like that.

Yepp, maybe 'useful (not only) for booking ...'


Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect.                              (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly."   (unknown)
Kaufbach, Saxony, Germany, Europe.              N 51.05082°, E 13.56889°

>> I second that.
>>
>> I too find the range types more important than a somewhat unfinished
>> JSON support (In my opinion it's missing indexing and access functions
>> to make it really usable)
>
> +1

So my problem is that I can't make it fit into a simple theme that the
general press will understand.  Performance+JSON is a simple theme.
Performance+WierdNewTypes is not.

Also, incomplete or not, the JSON support has already gotten far more
press attention than any other feature in 9.2.  Developer attention
also; at SCALE and PyCon, JSON support was the *only* 9.2 feature anyone
asked me about.  So JSON needs to stay in, fairly prominently.

Can someone suggest a way to work range types into a simple, 2-part
theme which doesn't obscure the JSON message?

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

>>> I second that.
>>>
>>> I too find the range types more important than a somewhat unfinished
>>> JSON support (In my opinion it's missing indexing and access functions
>>> to make it really usable)
>>
>> +1
>
> Can someone suggest a way to work range types into a simple, 2-part
> theme which doesn't obscure the JSON message?

Performance + Powerful Features
Performance + Power

Jonathan

Josh

Based on what I've been able to follow, I'd include JSON but indicate that
this is the first phase of the development of JSON. That will take the wind
out of any criticism that it will get for being less complete than the
opposition. I would view it as a promise of further improvement in 9.3.

On 8/08/12 4:37 AM, "Josh Berkus" <josh@agliodbs.com> wrote:
>
> So my problem is that I can't make it fit into a simple theme that the
> general press will understand.  Performance+JSON is a simple theme.
> Performance+WierdNewTypes is not.
>
> Also, incomplete or not, the JSON support has already gotten far more
> press attention than any other feature in 9.2.  Developer attention
> also; at SCALE and PyCon, JSON support was the *only* 9.2 feature anyone
> asked me about.  So JSON needs to stay in, fairly prominently.
>
> Can someone suggest a way to work range types into a simple, 2-part
> theme which doesn't obscure the JSON message?

As for the WeirdNewTypes, it needs a simple lo-tech way of explaining it.
Maybe a short, simple example of how it is applied.

Rob

On 08/07/2012 02:00 PM, Rob Napier wrote:

>> Can someone suggest a way to work range types into a simple, 2-part
>> theme which doesn't obscure the JSON message?
>
> As for the WeirdNewTypes, it needs a simple lo-tech way of explaining it.
> Maybe a short, simple example of how it is applied.

"CoolNewTypes"

Weird implies well wierd, they aren't weird, they are cool, hot, nifty,
rocking.

jD

>
> Rob
>
>
>
>


--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC
@cmdpromptinc - 509-416-6579

Joshua

Don't shoot the messenger. I'm just quoting Josh. And, BTW, from my
experience as a dbIgnoramus, I have to agree with his description.

To all you dbExperts on this list, I'd like to mention my own recent
experience with PostgreSQL that demonstrates the barrier to entry for people
trying to swing across from MySQL or other databases.

I decided recently that I would make time to really try to understand the
features and benefits of PostgreSQL. Thanks to the great Enterprise DB
installer package, I was able to install the software without any problems.
One barrier down!

And I found the wiki documentation really easy to follow, up to the point
when it starts to jump into object-relational blah blah blah.

Yes, I understand OOP and relational databases but when applied together,
the language is almost meaningless and more importantly: its significance to
me in developing a database. So I went to Wikipedia and elsewhere for an
explanation. That was worse. Much worse.

I've been building successful database applications for 25 years without a
problem. So I though the transition to PostgreSQL would not be too
difficult. Well, it is - if you haven't graduated from college in the last
10 years or invested 1000s of hours in private study.

Unless you folk want to continue being an object-relatively exclusive club,
you need to make information more accessible. I can cite numerous examples
in other industries where the second-or-third-best product dominates the
market by keeping the message simple and the product accessible.

So here is my offer: I am prepared to work (on Skype) with one or more
individuals who can explain the significance of Josh's no doubt,
illuminating announcement, and I'll write a media release for the rest of us
mortals.

And I'm willing to do this on any PostgreSQL text, as long as there is
someone ready to give me context to work with.

If there is a really well-written book that would break down the barriers
for me, what is its title? My PostgreSQL textbook would stop a tank!

Getting the right balance seems to be a problem. But it's a problem that
needs to be solved if mere mortals such as myself are ever going to make the
transition.

Apologies for the length of this post. Thank you for your time.

Rob Napier

On 8/08/12 7:08 AM, "Joshua D. Drake" <jd@commandprompt.com> wrote:

>
> On 08/07/2012 02:00 PM, Rob Napier wrote:
>
>>> Can someone suggest a way to work range types into a simple, 2-part
>>> theme which doesn't obscure the JSON message?
>>
>> As for the WeirdNewTypes, it needs a simple lo-tech way of explaining it.
>> Maybe a short, simple example of how it is applied.
>
> "CoolNewTypes"
>
> Weird implies well wierd, they aren't weird, they are cool, hot, nifty,
> rocking.
>
> jD
>

"Joshua D. Drake" <jd@commandprompt.com> wrote:
> On 08/07/2012 02:00 PM, Rob Napier wrote:
>
>>> Can someone suggest a way to work range types into a simple,
>>> 2-part theme which doesn't obscure the JSON message?
>>
>> As for the WeirdNewTypes, it needs a simple lo-tech way of
>> explaining it.  Maybe a short, simple example of how it is
>> applied.
>
> "CoolNewTypes"
>
> Weird implies well wierd, they aren't weird, they are cool, hot,
> nifty, rocking.

Yeah, if we need to punch just two points, with the ability to
elaborate a little, I would say performance (with emphasis on being
able to scale well to larger volumes and big new hardware) and new
types to simplify life for application programmers (JSON and
ranges).

JSON is all the rage with web-oriented programmers.  There is a
group of people for whom there pretty much couldn't be bigger
PostgreSQL news than this feature.  When we get to the day that we
have an HTTP access method that provides a "RESTful" interface to
database data through JSON, the web programmmers here will probably
throw a big party over how easy we've made their work.  9.2 doesn't
take it all the way there, but it is a giant leap in that direction,
which will cause some jaws to drop around here.

On the other hand, I suspect that ranges will get wider adoption,
because there are so many places that they make existing queries
simpler and faster, regardless of whether you are web-oriented.  The
obvious applications are related to scheduling, but I suspect it
will be put to many other uses.

-Kevin

 Tirsdag 7. august 2012 23.45.31 skrev Rob Napier :
> I've been building successful database applications for 25 years without a
> problem. So I though the transition to PostgreSQL would not be too
> difficult. Well, it is - if you haven't graduated from college in the last
> 10 years or invested 1000s of hours in private study.

I think that's a mild exaggeration. I found my way to Postgres from MySQL in
2005, and didn't find it particularly hard. I tend to think of myself as a
regular Joe Sixpack type, although I started with CP/M around 1984 and was a
UNIX sysadmin in the Nineties, and never became much impressed by the Redmond
Click-o-Rama paradigm. You may call me a command-line freak if that suits you.

I came to Postgres because I was in the process of developing my own genealogy
database, and was disgusted by MySQL's "relaxed" error-checking. I have never
looked back.

> Unless you folk want to continue being an object-relatively exclusive club,
> you need to make information more accessible. I can cite numerous examples
> in other industries where the second-or-third-best product dominates the
> market by keeping the message simple and the product accessible.

Postgres may appear "geeky" if you judge it by the most verbal part of the
community alone, but from a DB developer's POV it's not harder to work with
than most other RDBMSes. It's certainly different from MySQL, but I for one find
that to be more of an asset than a liability.

regards, Leif
http://code.google.com/p/yggdrasil-genealogy/

Rob Napier wrote on 07.08.2012 23:45:
> And I found the wiki documentation really easy to follow, up to the point
> when it starts to jump into object-relational blah blah blah.

Why the wiki and not the "real" manual? I find it (the manual) at least as easy to read as
the MySQL manual (in fact I find it better structured than MySQL's manual)

The manual hardly ever talks about "object relational" stuff. Only where
table inheritance is documented and for partitioning (which is using
table inheritance).

> "Joshua D. Drake" <jd@commandprompt.com> wrote:
>> On 08/07/2012 02:00 PM, Rob Napier wrote:
>>
>>>> Can someone suggest a way to work range types into a simple,
>>>> 2-part theme which doesn't obscure the JSON message?
>>>
>>> As for the WeirdNewTypes, it needs a simple lo-tech way of
>>> explaining it.  Maybe a short, simple example of how it is
>>> applied.
>>
>> "CoolNewTypes"
>>
>> Weird implies well wierd, they aren't weird, they are cool, hot,
>> nifty, rocking.
>
> Yeah, if we need to punch just two points, with the ability to
> elaborate a little, I would say performance (with emphasis on being
> able to scale well to larger volumes and big new hardware) and new
> types to simplify life for application programmers (JSON and
> ranges).
>
> JSON is all the rage with web-oriented programmers.  There is a
> group of people for whom there pretty much couldn't be bigger
> PostgreSQL news than this feature.  When we get to the day that we
> have an HTTP access method that provides a "RESTful" interface to
> database data through JSON, the web programmmers here will probably
> throw a big party over how easy we've made their work.  9.2 doesn't
> take it all the way there, but it is a giant leap in that direction,
> which will cause some jaws to drop around here.

From a marketing perspective, touting the JSON support will definitely get some more eyeballs from the web community.
Beingin the web in the  "web-oriented programmer" category myself, if I were to further look into the 9.2 JSON support,
Iwould come away wondering what the "hype" is with it as, on a functional basis, it just ensures that I store valid
JSONin the database.  If I had to do any more serious data processing on evaluation and would prefer to do it at the
databaselevel, I would look at another data source. 

As I said before, I'm glad Postgres is starting to have JSON support (I've randomly bugged people for it through the
years:-), but we do need to make sure we point out our strengths. 

> On the other hand, I suspect that ranges will get wider adoption,
> because there are so many places that they make existing queries
> simpler and faster, regardless of whether you are web-oriented.  The
> obvious applications are related to scheduling, but I suspect it
> will be put to many other uses.

+1 and especially for a  "web-oriented developer, " once you understand what ranges can do, you suddenly have a lot of
veryfast querying options :-) For instance, just about anything involving a "slider" UI element that on a web page that
goesinto a search can be turned into a range query.  At the end of the day, most web-developers care about speed and
simpleways to extract performance out of the tools they are using. 

Jonathan

You're right. I meant the manual. And I agree. It is well written for its audience.

But my reference to object- relational was just intended as an example of what you DB professionals live with day in
andday out.but we, the great unwashed, do find it difficult to get started. 

Citing individual successes misses the point. The success of MySQL, FileMaker, Access et al proves that there is a big
marketopportunity being missed. 

No, those applications don't interest the experts but it adds indirectly to the overall success of the product.

I wonder what percentage of developers started out with Access.

Rob Napier



On 08/08/2012, at 8:19 AM, Thomas Kellerer <spam_eater@gmx.net> wrote:

> Rob Napier wrote on 07.08.2012 23:45:
>> And I found the wiki documentation really easy to follow, up to the point
>> when it starts to jump into object-relational blah blah blah.
>
> Why the wiki and not the "real" manual? I find it (the manual) at least as easy to read as
> the MySQL manual (in fact I find it better structured than MySQL's manual)
>
> The manual hardly ever talks about "object relational" stuff. Only where
> table inheritance is documented and for partitioning (which is using
> table inheritance).
>
>
>
>
>
> --
> Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-advocacy
>

>> Yeah, if we need to punch just two points, with the ability to
>> elaborate a little, I would say performance (with emphasis on being
>> able to scale well to larger volumes and big new hardware) and new
>> types to simplify life for application programmers (JSON and
>> ranges).

So I'd like to see some draft language for the 2nd section of the
release.  So far, there's been a lot of general suggestions, but what
I'm having trouble with is the specific language for the release, not
the concepts.


--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

Regarding JSON, I would suggest adding XML alongside HSTORE as related features which allow a No-SQL-like approach.  JSON and XML can be thought of as equivalent formats (alongside HSTORE) and while there are perhaps different features there, it helps emphasize the flexibility that PostgreSQL has in these areas.