Re: [HACKERS] 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'. ... 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. hmm.. shock it is this shift for 9.1 due in mid 2011 is unexpectedly soon :) Curious to understand as to - how this relates to every feature that is provide at the moment based on RDBMS paradigm. ACID compliance, support for the features provided by SQL, referential integrity, joins, caching etc, .. - Also does this shift take into an assumption that all the use cases fit the likes of data access patterns usecases similar to facebook/twitter? or to address the the likes of those ? Thanks, Raj
Re: [HACKERS] Postgres 9.1 - Release Theme
I was under the impression that QUEL was actually a good language in some ways, and that it was more relational and better than SQL in some ways. http://en.wikipedia.org/wiki/QUEL_query_languages Maybe bringing it back would be a good idea, but as an alternative to SQL rather than a replacement. In any event, QUEL was somewhat similar to SQL. -- Darren Duncan Rajasekhar Yakkali 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'. ... 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. hmm.. shock it is this shift for 9.1 due in mid 2011 is unexpectedly soon :) Curious to understand as to - how this relates to every feature that is provide at the moment based on RDBMS paradigm. ACID compliance, support for the features provided by SQL, referential integrity, joins, caching etc, .. - Also does this shift take into an assumption that all the use cases fit the likes of data access patterns usecases similar to facebook/twitter? or to address the the likes of those ? Thanks, Raj -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Postgres 9.1 - Release Theme
On 1 April 2010 09:13, Dave Page dp...@postgresql.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
Re: [HACKERS] Postgres 9.1 - Release Theme
On Thu, Apr 1, 2010 at 9:30 AM, Thom Brown thombr...@gmail.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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Postgres 9.1 - Release Theme
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! ;) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Postgres 9.1 - Release Theme
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 dp...@postgresql.org wrote: On Thu, Apr 1, 2010 at 9:30 AM, Thom Brown thombr...@gmail.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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [GENERAL] [HACKERS] Postgres 9.1 - Release Theme
2010/4/1 Thom Brown thombr...@gmail.com: On 1 April 2010 09:13, Dave Page dp...@postgresql.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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [GENERAL] [HACKERS] Postgres 9.1 - Release Theme
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [GENERAL] [HACKERS] Postgres 9.1 - Release Theme
On Thu, Apr 1, 2010 at 10:05 AM, David E. Wheeler da...@kineticode.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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [GENERAL] [HACKERS] Postgres 9.1 - Release Theme
On Thu, 2010-04-01 at 10:54 -0600, Scott Marlowe wrote: On Thu, Apr 1, 2010 at 10:05 AM, David E. Wheeler da...@kineticode.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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [GENERAL] [HACKERS] Postgres 9.1 - Release Theme
On 04/01/2010 09:54 AM, Scott Marlowe wrote: On Thu, Apr 1, 2010 at 10:05 AM, David E. Wheelerda...@kineticode.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.kla...@gmail.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
