Postgres 9.1 - Release Theme

Following a great deal of discussion, I'm pleased to announce that the
PostgreSQL Core team has decided that the major theme for the 9.1
release, due in 2011, will be 'NoSQL'.

There is a growing trend towards NoSQL databases, with major sites
like Twitter and Facebook utilising them extensively. NoSQL databases
often include multi-master replication, clustering and failover
features that have long been requested in PostgresSQL, but have been
extremely difficult to implement with SQL which has prevented us from
advancing Postgree in the way that we'd like.

To address this, the intention is to remove SQL support from
Postgres, and replace it with a language called 'QUEL'. This will
provide us with the flexibility we need to implement the features of
modern NoSQL databases. With no SQL support there will obviously be
some differences in the query syntax that must be used to access your
data. For example, the query:

select (e.salary/ (e.age - 18)) as comp from employee as e where
e.name = "Jones"

would be rewritten as:

range of e is employee retrieve (comp = e.salary/ (e.age - 18)) where
e.name = "Jones"

Aggregate syntax in QUEL is particularly powerful. For example, the query:

select dept,
avg(salary) as avg_salary,
sum(salary) as tot_salary
from
employees
group by
dept

may be written as:

range of e is employee
retrieve (e.dept,
avg_salary = avg(e.salary by e.dept),
tot_salary = sum(e.salary by e.dept)
)

Note that the grouped column can be specified for each individual
aggregate.

We will be producing a comprehensive guide to the QUEL syntax to aid
with application migration. We appreciate the difficulty that this
change may cause some users, but feel we must embrace the NoSQL
philosophy in order to remain "The world's most advanced Open Source
database"

"There's no question that, at 21 years old, the SQL standard is past its
prime," said core developer and standards expert Peter Eisentraut. "It's
time for us to switch to something fresher. I personally would have
preferred XSLT, but QUEL is almost as good."

Project committer Heikki Linnakangas added: "By replacing SQL with
QUEL not only will will be able to add new features to Postgres that
were previously too difficult, but we'll also increase user loyalty as it'll
be much harder for them to change to a different, SQL-based
database. That'll be pretty cool."

You may also notice that without SQL, the project name is somewhat
misleading. To address that, the project name will be changed to
'PostgreQUEL' with the 9.1 release. We expect this will also put an
end to the periodic debates on changing the project name.

Dave Page
On behalf of the PostgreSQL Core Team

Hi Dave,

thanks for this funny post on April, 1st ;-)

It's currently the highlight of my working day here....

regards..GERD..

On Thursday 01 April 2010 10:13:16 am Dave Page wrote:
> Following a great deal of discussion, I'm pleased to announce that the
> PostgreSQL Core team has decided that the major theme for the 9.1
> release, due in 2011, will be 'NoSQL'.
>
> There is a growing trend towards NoSQL databases, with major sites
> like Twitter and Facebook utilising them extensively. NoSQL databases
> often include multi-master replication, clustering and failover
> features that have long been requested in PostgresSQL, but have been
> extremely difficult to implement with SQL which has prevented us from
> advancing Postgree in the way that we'd like.
>
> To address this, the intention is to remove SQL support from
> Postgres, and replace it with a language called 'QUEL'. This will
> provide us with the flexibility we need to implement the features of
> modern NoSQL databases. With no SQL support there will obviously be
> some differences in the query syntax that must be used to access your
> data. For example, the query:
>
> select (e.salary/ (e.age - 18)) as comp from employee as e where
> e.name = "Jones"
>
> would be rewritten as:
>
> range of e is employee retrieve (comp = e.salary/ (e.age - 18)) where
> e.name = "Jones"
>
> Aggregate syntax in QUEL is particularly powerful. For example, the query:
>
> select dept,
> avg(salary) as avg_salary,
> sum(salary) as tot_salary
> from
> employees
> group by
> dept
>
> may be written as:
>
> range of e is employee
> retrieve (e.dept,
> avg_salary = avg(e.salary by e.dept),
> tot_salary = sum(e.salary by e.dept)
> )
>
> Note that the grouped column can be specified for each individual
> aggregate.
>
> We will be producing a comprehensive guide to the QUEL syntax to aid
> with application migration. We appreciate the difficulty that this
> change may cause some users, but feel we must embrace the NoSQL
> philosophy in order to remain "The world's most advanced Open Source
> database"
>
> "There's no question that, at 21 years old, the SQL standard is past its
> prime," said core developer and standards expert Peter Eisentraut. "It's
> time for us to switch to something fresher. I personally would have
> preferred XSLT, but QUEL is almost as good."
>
> Project committer Heikki Linnakangas added: "By replacing SQL with
> QUEL not only will will be able to add new features to Postgres that
> were previously too difficult, but we'll also increase user loyalty as
> it'll be much harder for them to change to a different, SQL-based
> database. That'll be pretty cool."
>
> You may also notice that without SQL, the project name is somewhat
> misleading. To address that, the project name will be changed to
> 'PostgreQUEL' with the 9.1 release. We expect this will also put an
> end to the periodic debates on changing the project name.
>
> Dave Page
> On behalf of the PostgreSQL Core Team

--
/====================================\
| Gerd König
| - Service Manager IT -
|
| TRANSPOREON GmbH
| Magirus-Deutz-Str. 16
| DE - 89077 Ulm
|
| Tel: +49 [0]731 16906 106
| Fax: +49 [0]731 16906 99
| koenig(at)transporeon(dot)com
| www.transporeon.com
|
\====================================/

TTRANSPOREON GmbH, District Court Ulm, HRB 722056,
Directors: Peter Förster, Roland Hötzl, Martin Mack, Marc-Oliver Simon

On 1 April 2010 09:13, Dave Page <dpage(at)postgresql(dot)org> wrote:

> Following a great deal of discussion, I'm pleased to announce that the
> PostgreSQL Core team has decided that the major theme for the 9.1
> release, due in 2011, will be 'NoSQL'.
>
> There is a growing trend towards NoSQL databases, with major sites
> like Twitter and Facebook utilising them extensively. NoSQL databases
> often include multi-master replication, clustering and failover
> features that have long been requested in PostgresSQL, but have been
> extremely difficult to implement with SQL which has prevented us from
> advancing Postgree in the way that we'd like.
>
> To address this, the intention is to remove SQL support from
> Postgres, and replace it with a language called 'QUEL'. This will
> provide us with the flexibility we need to implement the features of
> modern NoSQL databases. With no SQL support there will obviously be
> some differences in the query syntax that must be used to access your
> data. For example, the query:
>
> select (e.salary/ (e.age - 18)) as comp from employee as e where
> e.name = "Jones"
>
> would be rewritten as:
>
> range of e is employee retrieve (comp = e.salary/ (e.age - 18)) where
> e.name = "Jones"
>
> Aggregate syntax in QUEL is particularly powerful. For example, the query:
>
> select dept,
> avg(salary) as avg_salary,
> sum(salary) as tot_salary
> from
> employees
> group by
> dept
>
> may be written as:
>
> range of e is employee
> retrieve (e.dept,
> avg_salary = avg(e.salary by e.dept),
> tot_salary = sum(e.salary by e.dept)
> )
>
> Note that the grouped column can be specified for each individual
> aggregate.
>
> We will be producing a comprehensive guide to the QUEL syntax to aid
> with application migration. We appreciate the difficulty that this
> change may cause some users, but feel we must embrace the NoSQL
> philosophy in order to remain "The world's most advanced Open Source
> database"
>
> "There's no question that, at 21 years old, the SQL standard is past its
> prime," said core developer and standards expert Peter Eisentraut. "It's
> time for us to switch to something fresher. I personally would have
> preferred XSLT, but QUEL is almost as good."
>
> Project committer Heikki Linnakangas added: "By replacing SQL with
> QUEL not only will will be able to add new features to Postgres that
> were previously too difficult, but we'll also increase user loyalty as
> it'll
> be much harder for them to change to a different, SQL-based
> database. That'll be pretty cool."
>
> You may also notice that without SQL, the project name is somewhat
> misleading. To address that, the project name will be changed to
> 'PostgreQUEL' with the 9.1 release. We expect this will also put an
> end to the periodic debates on changing the project name.
>
> Dave Page
> On behalf of the PostgreSQL Core Team
>
>
I prefer to dump all my data in a big text file and grep it for the
information I need.

Thom

On Thu, Apr 1, 2010 at 9:30 AM, Thom Brown <thombrown(at)gmail(dot)com> wrote:
> I prefer to dump all my data in a big text file and grep it for the
> information I need.

There's no need to start showing off and get all technical y'know.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Ciao Dave,

> You may also notice that without SQL, the project name is somewhat
> misleading. To address that, the project name will be changed to
> 'PostgreQUEL' with the 9.1 release. We expect this will also put an
> end to the periodic debates on changing the project name.

Ahahahah ... nice fish! ;)

Nice to hear and thumbs up! I've just start planning to migrate one of
my telco 3Tb database running blunt oracle to coachDb but now of
course postgres looks better. Hopefully stupid transactions will be
abrogated to

wbr Ilya

On Thu, Apr 1, 2010 at 12:33 PM, Dave Page <dpage(at)postgresql(dot)org> wrote:
> On Thu, Apr 1, 2010 at 9:30 AM, Thom Brown <thombrown(at)gmail(dot)com> wrote:
>> I prefer to dump all my data in a big text file and grep it for the
>> information I need.
>
> There's no need to start showing off and get all technical y'know.
>
> --
> Dave Page
> EnterpriseDB UK: http://www.enterprisedb.com
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

2010/4/1 Thom Brown <thombrown(at)gmail(dot)com>:
> On 1 April 2010 09:13, Dave Page <dpage(at)postgresql(dot)org> wrote:
>>
>> Following a great deal of discussion, I'm pleased to announce that the
>> PostgreSQL Core team has decided that the major theme for the 9.1
>> release, due in 2011, will be 'NoSQL'.
>>
>> There is a growing trend towards NoSQL databases, with major sites
>> like Twitter and Facebook utilising them extensively. NoSQL databases
>> often include multi-master replication, clustering and failover
>> features that have long been requested in PostgresSQL, but have been
>> extremely difficult to implement with SQL which has prevented us from
>> advancing Postgree in the way that we'd like.
>>
>> To address this, the intention is to remove SQL support from
>> Postgres, and replace it with a language called 'QUEL'. This will
>> provide us with the flexibility we need to implement the features of
>> modern NoSQL databases. With no SQL support there will obviously be
>> some differences in the query syntax that must be used to access your
>> data. For example, the query:
>>
>> select (e.salary/ (e.age - 18)) as comp from employee as e where
>> e.name = "Jones"
>>
>> would be rewritten as:
>>
>> range of e is employee retrieve (comp = e.salary/ (e.age - 18)) where
>> e.name = "Jones"
>>
>> Aggregate syntax in QUEL is particularly powerful. For example, the query:
>>
>> select dept,
>>      avg(salary) as avg_salary,
>>      sum(salary) as tot_salary
>> from
>>      employees
>> group by
>>      dept
>>
>> may be written as:
>>
>> range of e is employee
>> retrieve (e.dept,
>>         avg_salary = avg(e.salary by e.dept),
>>         tot_salary = sum(e.salary by e.dept)
>> )
>>
>> Note that the grouped column can be specified for each individual
>> aggregate.
>>
>> We will be producing a comprehensive guide to the QUEL syntax to aid
>> with application migration. We appreciate the difficulty that this
>> change may cause some users, but feel we must embrace the NoSQL
>> philosophy in order to remain "The world's most advanced Open Source
>> database"
>>
>> "There's no question that, at 21 years old, the SQL standard is past its
>> prime," said core developer and standards expert Peter Eisentraut. "It's
>> time for us to switch to something fresher.  I personally would have
>> preferred XSLT, but QUEL is almost as good."
>>
>> Project committer Heikki Linnakangas added: "By replacing SQL with
>> QUEL not only will will be able to add new features to Postgres that
>> were previously too difficult, but we'll also increase user loyalty as it'll
>> be much harder for them to change to a different, SQL-based
>> database. That'll be pretty cool."
>>
>> You may also notice that without SQL, the project name is somewhat
>> misleading. To address that, the project name will be changed to
>> 'PostgreQUEL' with the 9.1 release. We expect this will also put an
>> end to the periodic debates on changing the project name.
>>
>> Dave Page
>> On behalf of the PostgreSQL Core Team
>>
>
> I prefer to dump all my data in a big text file and grep it for the information I need.

As long as you implement your own grep, that sounds about on par with
the current trends! Go for it!

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

> Following a great deal of discussion, I'm pleased to announce that the
> PostgreSQL Core team has decided that the major theme for the 9.1
> release, due in 2011, will be 'NoSQL'.
>

Please, provide me your address so I can forward you the "health care"
bills I had to pay due to the heart attack I suffered this morning (when
reading your post).

BTW PostgreSQL core team is not alone realizing how obsolete relational
databases are:
http://thedailywtf.com/Articles/Announcing-APDB-The-Worlds-Fastest-Database.aspx

Tomas

On Apr 1, 2010, at 3:01 AM, Magnus Hagander wrote:

>> I prefer to dump all my data in a big text file and grep it for the information I need.
>
> As long as you implement your own grep, that sounds about on par with
> the current trends! Go for it!

Well, first you have to implement your own compiler. Also a lexer and a parser.

David

2010/4/1 <tv(at)fuzzy(dot)cz>:
>> Following a great deal of discussion, I'm pleased to announce that the
>> PostgreSQL Core team has decided that the major theme for the 9.1
>> release, due in 2011, will be 'NoSQL'.
>>
>
> Please, provide me your address so I can forward you the "health care"
> bills I had to pay due to the heart attack I suffered this morning (when
> reading your post).

:-p

> BTW PostgreSQL core team is not alone realizing how obsolete relational
> databases are:
> http://thedailywtf.com/Articles/Announcing-APDB-The-Worlds-Fastest-Database.aspx

Yeah, I read that earlier in my daily lunchtime jaunt over to the
Daily WTF. Alex clearly spent more time on his text than I did!

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

On Thu, Apr 1, 2010 at 10:05 AM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> On Apr 1, 2010, at 3:01 AM, Magnus Hagander wrote:
>
>>> I prefer to dump all my data in a big text file and grep it for the information I need.
>>
>> As long as you implement your own grep, that sounds about on par with
>> the current trends! Go for it!
>
> Well, first you have to implement your own compiler. Also a lexer and a parser.

All that will be for naught unless you hand wire your own logic
boards. I mean really, come on.

On Thu, 2010-04-01 at 10:54 -0600, Scott Marlowe wrote:
> On Thu, Apr 1, 2010 at 10:05 AM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> > On Apr 1, 2010, at 3:01 AM, Magnus Hagander wrote:
> >
> >>> I prefer to dump all my data in a big text file and grep it for the information I need.
> >>
> >> As long as you implement your own grep, that sounds about on par with
> >> the current trends! Go for it!
> >
> > Well, first you have to implement your own compiler. Also a lexer and a parser.
>
> All that will be for naught unless you hand wire your own logic
> boards. I mean really, come on.

I hate April 1st.

>

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.

On 04/01/2010 09:54 AM, Scott Marlowe wrote:
> On Thu, Apr 1, 2010 at 10:05 AM, David E. Wheeler<david(at)kineticode(dot)com> wrote:
>> On Apr 1, 2010, at 3:01 AM, Magnus Hagander wrote:
>>
>>>> I prefer to dump all my data in a big text file and grep it for the information I need.
>>>
>>> As long as you implement your own grep, that sounds about on par with
>>> the current trends! Go for it!
>>
>> Well, first you have to implement your own compiler. Also a lexer and a parser.
>
> All that will be for naught unless you hand wire your own logic
> boards. I mean really, come on.
>

Actually I think this calls for quantum computing
(http://en.wikipedia.org/wiki/Quantum_computer). The intersection of
NoSQL and Quantum decoherence is almost to good to be true.

--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com