Proper relational database?

On Thu, Apr 21, 2016 at 1:36 PM, Guyren Howe <guyren@gmail.com> wrote:

If I had a few $million to spend in a philanthropical manner, I would hire some of the best PG devs to develop a proper relational database server. Probably a query language that expressed the relational algebra in a scheme-like syntax, and the storage model would be properly relational (eg no duplicate rows).

Have you heard of QUEL?

See https://en.wikipedia.org/wiki/QUEL_query_languages

--
Peter Geoghegan

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Thu, Apr 21, 2016 at 1:36 PM, Guyren Howe <guyren@gmail.com> wrote:

Anyone familiar with the issue would have to say that the tech world would
be a significantly better place if IBM had developed a real relational
database with an elegant query language rather than the awful camel of a
thing that is SQL.

If I had a few $million to spend in a philanthropical manner, I would hire
some of the best PG devs to develop a proper relational database server.
Probably a query language that expressed the relational algebra in a
scheme-like syntax, and the storage model would be properly relational (eg
no duplicate rows).

It's an enormous tragedy that all the development effort that has gone
into NoSQL database has pretty much all gotten it wrong: by all means throw
out SQL, but not the relational model with it. They're all just rehashing
the debate over hierarchical storage from the 70s. Comp Sci courses should
feature a history class.

It's a bit odd to me that someone isn't working on such a thing.

Just curious what folks here have to say…

​Transpiling

​Having learned SQL you come to appreciate its warts and inefficiencies -
but I have no doubt that any other attempt at the same goal would have its
own, different, set of complaints.

​My tables don't have duplicates and while extra care need be taken
automatic duplicate removal also has the property of potentially hiding
bugs - whether more or less than non-removal I cannot say.

​David J.

Just as a curiosity, what do you think of ANDL?

http://www.andl.org/welcome-to-andl/

The developer has been posting some questions here about interfacing it to
PostgreSQL. But he doesn't just want to do a "translate the ANDL language
to SQL language"

On Thu, Apr 21, 2016 at 3:36 PM, Guyren Howe <guyren@gmail.com> wrote:

Anyone familiar with the issue would have to say that the tech world would
be a significantly better place if IBM had developed a real relational
database with an elegant query language rather than the awful camel of a
thing that is SQL.

If I had a few $million to spend in a philanthropical manner, I would hire
some of the best PG devs to develop a proper relational database server.
Probably a query language that expressed the relational algebra in a
scheme-like syntax, and the storage model would be properly relational (eg
no duplicate rows).

It's an enormous tragedy that all the development effort that has gone
into NoSQL database has pretty much all gotten it wrong: by all means throw
out SQL, but not the relational model with it. They're all just rehashing
the debate over hierarchical storage from the 70s. Comp Sci courses should
feature a history class.

It's a bit odd to me that someone isn't working on such a thing.

Just curious what folks here have to say…

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

--
"He must have a Teflon brain -- nothing sticks to it"
Phyllis Diller

Maranatha! <><
John McKown

Well, this hits very close to my feelings in several respects. I
don't often bring this up, because I don't generally feel like "I
loathe SQL" is quite the thing to say in a community called
"PostgreSQL". :-) Or, "I really love this project... can we change
its direction entirely?"

But yeah, that's in my heart. And I'm quite in agreement on NoSQL. I
don't think a lot of people realize there *is* a difference between
"relational" and SQL, so the baby goes out with the bathwater.

As it just so happens, I actually hacked a Scheme interpreter into the
PostgreSQL parser, and got it to interpret incoming messages, with
virtually the same idea. I started messing with generating SQL from
S-expressions, with the idea to perhaps call query-building functions
later on. I started off with Chibi Scheme, and moved to Chicken later
on, mostly because the folks in the Chicken IRC channel are so
helpful. I was wondering whether PostgreSQL might consider supporting
alternative query languages, similar to the way it supports multiple
languages for stored procedures. Ideally, it'd be nice to get the
query results as S-expressions also.

On Thu, Apr 21, 2016 at 4:36 PM, Guyren Howe <guyren@gmail.com> wrote:

Anyone familiar with the issue would have to say that the tech world would be a significantly better place if IBM had developed a real relational database with an elegant query language rather than the awful camel of a thing that is SQL.

If I had a few $million to spend in a philanthropical manner, I would hire some of the best PG devs to develop a proper relational database server. Probably a query language that expressed the relational algebra in a scheme-like syntax, and the storage model would be properly relational (eg no duplicate rows).

It's an enormous tragedy that all the development effort that has gone into NoSQL database has pretty much all gotten it wrong: by all means throw out SQL, but not the relational model with it. They're all just rehashing the debate over hierarchical storage from the 70s. Comp Sci courses should feature a history class.

It's a bit odd to me that someone isn't working on such a thing.

Just curious what folks here have to say…

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

--
Ray Brinzer

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Apr 21, 2016, at 13:56 , John McKown <john.archie.mckown@gmail.com> wrote:

Just as a curiosity, what do you think of ANDL?

http://www.andl.org/welcome-to-andl/ <http://www.andl.org/welcome-to-andl/&gt;

The developer has been posting some questions here about interfacing it to PostgreSQL. But he doesn't just want to do a "translate the ANDL language to SQL language"

A brief review of it says it would be better than SQL, but then almost anything would be. But the syntax looks a bit… baroque. Quell similarly.

If I had the time and money to put together a team to do this, I would start with the lower-level guts of either Postgres or SQLite (or, heck, MySQL) so you had a thing that did BTrees and other data structures on disk and indexes, and provide access to that from a high level, portable and efficient language. Perhaps Scheme.

Then you could write a high-level relational logic engine on top of that, in the high level language, perhaps with the odd bit of C or D or Go for anything really critical.

I don't know if Postgres exposes the lower-level stuff to plugins or not — it would be nice if this could be an alternative query language for Postgres itself, but the assumptions about the two worlds (SQL vs a properly relational store) are probably too different.

As I say, it amazes and somewhat depresses me that someone isn't doing this. The NoSQL movement shows that the world is ready for change. Someone should be offering folks something better than bloody MongoDB.

And the project could adopt the spirit of the good parts of the NoSQL movement. I should be able to have a lightweight, distributed schema-on-demand, eventually consistent etc etc *relational* data store.

Please don't get me wrong. I *adore* Postgres. It is for most projects hands-down the best data store available. It's just tragic that this amazing project is so wedded to the awfulness that is SQL.

I wrote about such issues at a bit more length at http://relevantlogic.com/2015/11/04/no-sql-is-fixing-the-wrong-problem.html <http://relevantlogic.com/2015/11/04/no-sql-is-fixing-the-wrong-problem.html&gt;

On Thursday 21 April 2016 13:36:54 Guyren Howe wrote:

Anyone familiar with the issue would have to say that the tech world would
be a significantly better place if IBM had developed a real relational
database with an elegant query language rather than the awful camel of a
thing that is SQL.

If I had a few $million to spend in a philanthropical manner, I would hire
some of the best PG devs to develop a proper relational database server.
Probably a query language that expressed the relational algebra in a
scheme-like syntax, and the storage model would be properly relational (eg
no duplicate rows).

It's an enormous tragedy that all the development effort that has gone into
NoSQL database has pretty much all gotten it wrong: by all means throw out
SQL, but not the relational model with it. They're all just rehashing the
debate over hierarchical storage from the 70s. Comp Sci courses should
feature a history class.

It's a bit odd to me that someone isn't working on such a thing.

Just curious what folks here have to say…

Well when IBM were first developing relational databases there were two
different teams. One in California which produced System-R which became
what we now know as DB2 and spawned SQL, and the other in Peterlee in
the UK which was called PRTV (the Peterlee Relational Test Vehicle). PRTV
rather died but bits of it survived. In particular it was the first to system
to include a relational optimiser. You can find some details on the PRTV
page in Wikipedia.

It was written in PL/1, although it also used some modified microcode
and therefore some assembler.

It never appeared as a product, but there was a geographical system
which built on top of it which was if I recall corrected used by the Greater
London Council and Central Region Scotland, which did something of
what postgis does for PostgreSQL.

According to the Wikipedia page it did have a language (ISBL) but from what
I recall (and it was nearly 40 years ago) there were a series of PL/1
function calls we used rather than encoding the request as a string
as SQL systems require.

The IBM centre in Peterlee was closed, and the lab moved to Winchester
where I think it still resides.

David

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On 22 April 2016 at 07:05, Guyren Howe <guyren@gmail.com> wrote:

As I say, it amazes and somewhat depresses me that someone isn't doing this.
The NoSQL movement shows that the world is ready for change. Someone should
be offering folks something better than bloody MongoDB.

Please don't get me wrong. I *adore* Postgres. It is for most projects
hands-down the best data store available. It's just tragic that this amazing
project is so wedded to the awfulness that is SQL.

Can I make a counter-argument?

SQL is excellent for beginners and adequate for most users. The basic
syntax of SQL (enough that people can produce useful queries with it)
can be presented and understood by a novice in an afternoon. I would
balk at the idea of trying to present the sort of syntax that appears
on the ANDL website to people who aren't programmers, which (I'd be
tempted to suggest) is a significant proportion of the userbase of
SQL.

The fact that ORMs are horrible and involve far too much work to
maintain isn't the fault of SQL, it's the fault of the people who
believe that they have to have their data fed to them by an ORM,
because of this idea (that has sadly propagated widely) that the
separation of code from the data is somehow helpful (as is probably
obvious I'm yet to be convinced of that!).

The world is not "ready for a change". I think of NoSQL as being like
Kim Kardashian: it gets an awful lot of publicity without providing
much justification for it; it brings a lot of column inches without
giving anything of substance in return and a lot of people talk about
it an awful lot without really knowing much about it at all.

There's a (very) small set of users for whom NoSQL makes a lot of
sense. Most of those are large corporations with huge budgets for
development, or academics who can afford to spend many hours tweaking
and figuring out their optimum storage requirements. The average SQL
user, on the other hand, just wants something that brings consistent
data storage for their database that probably numbers in the tens of
thousands of records at most (and if it scales to tens of millions
then great).

Geoff

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Fri, Apr 22, 2016 at 1:05 AM, Guyren Howe <guyren@gmail.com> wrote:

A brief review of it says it would be better than SQL, but then almost
anything would be. But the syntax looks a bit… baroque. Quell similarly.

If I had the time and money to put together a team to do this, I would
start with the lower-level guts of either Postgres or SQLite (or, heck,
MySQL) so you had a thing that did BTrees and other data structures on disk
and indexes, and provide access to that from a high level, portable and
efficient language. Perhaps Scheme.

Then you could write a high-level relational logic engine on top of that,
in the high level language, perhaps with the odd bit of C or D or Go for
anything really critical.

I don't know if Postgres exposes the lower-level stuff to plugins or not —
it would be nice if this could be an alternative query language for
Postgres itself, but the assumptions about the two worlds (SQL vs a
properly relational store) are probably too different.

As I say, it amazes and somewhat depresses me that someone isn't doing
this. The NoSQL movement shows that the world is ready for change. Someone
should be offering folks something better than bloody MongoDB.

And the project could adopt the spirit of the good parts of the NoSQL
movement. I should be able to have a lightweight, distributed
schema-on-demand, eventually consistent etc etc *relational* data store.

Please don't get me wrong. I *adore* Postgres. It is for most projects
hands-down the best data store available. It's just tragic that this
amazing project is so wedded to the awfulness that is SQL.

I wrote about such issues at a bit more length at
http://relevantlogic.com/2015/11/04/no-sql-is-fixing-the-wrong-problem.html

​I am not a developer, but one thing interesting about SQLite is that it
appears to "compile" the SQL into a virtual machine language (ala Java &
byte code), then execute that. Now, if someone wanted to & had the talent,
it might be interesting to have another language which would compile into
the same VM language and so be executable by the SQLite VM interpreter. I
don't know if PostgreSQL does something similar or not. It may do a SQL to
VM, like Python. Or it may do something else. I need to read the
"internals" documentation on the web site.​

--
"He must have a Teflon brain -- nothing sticks to it"
Phyllis Diller

Maranatha! <><
John McKown

On Fri, Apr 22, 2016 at 2:05 AM, Guyren Howe <guyren@gmail.com> wrote:

If I had the time and money to put together a team to do this, I would start
with the lower-level guts of either Postgres or SQLite (or, heck, MySQL) so
you had a thing that did BTrees and other data structures on disk and
indexes, and provide access to that from a high level, portable and
efficient language. Perhaps Scheme.

Then you could write a high-level relational logic engine on top of that, in
the high level language, perhaps with the odd bit of C or D or Go for
anything really critical.

Why is starting at a low level important? A database is truly
relational to the extent that it implements the relational model. If
you don't want the database to allow tables without keys, or to allow
null values, don't let people create them. If the underlying machinery
allows them, that seems like a mere performance issue; worrying about
that from the outset seems like a perfect example of premature
optimization. If PostgreSQL's performance is acceptable now, why
wouldn't it be acceptable with a different interface language?

There are other aspects of what would make a truly relational
database, of course. Codd's 0th rule, for instance, that the "system
must be able to manage data bases entirely through its relational
capabilities" to me says that there should be no data definition
language, except as syntactic sugar for relational operations. So
you'd create users (thousands in one command, if you liked) by adding
tuples to a base relation.

But which things are important? I think a good many of the things one
might would be lower-hanging fruit than that. Just having a clean
query language would alleviate a lot of (my) discomfort.

I don't know if Postgres exposes the lower-level stuff to plugins or not —
it would be nice if this could be an alternative query language for Postgres
itself,

Well, the parser doesn't, but as best I can tell it's also somewhat
loosely coupled from the system. It doesn't do table access, for
instance. It builds and returns a parse tree. There's no reason you
couldn't parse a different language and return a tree of the same
type. Or you could just translate your input language into SQL, and
pass it along to the existing parser.

but the assumptions about the two worlds (SQL vs a properly
relational store) are probably too different.

Are there relational algebra expressions, or other operations
necessary to a truly relational database, which cannot be translated
into SQL? I'm not aware that there are, but I'd be interested to hear
of it. If there were, there's a good chance you wouldn't be able to
translate them into the parse tree, either.

--
Ray Brinzer

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Apr 22, 2016, at 10:45 , Raymond Brinzer <ray.brinzer@gmail.com> wrote:

Are there relational algebra expressions, or other operations
necessary to a truly relational database, which cannot be translated
into SQL? I'm not aware that there are, but I'd be interested to hear
of it. If there were, there's a good chance you wouldn't be able to
translate them into the parse tree, either.

The fundamental storage model needs to at least be a bit different. In particular, relations can't allow duplicates. You could have nulls (Codd proposed two different forms of null IIRC: a single null value and two different null values), although they should be more principled than the mess they are in SQL.

I am no expert on database optimization, but I understand that it is significantly easier to do query optimization in a properly relational database, as it forms a reasonably simple algebra, which can be optimized much as you would optimize evaluation of a numeric expression.

Major gains from a proper relational store would be:

- a better language, easier to parse, read and generate. Perhaps multiple equivalent query languages;
- other storage models (distributed and eventually consistent, say);
- simpler (in implementation and use);

We may also get some degree of faster and other good things. It also might be implemented in such a way that it can run as a server or more like SQLite.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On 04/22/2016 06:21 AM, David Goodenough wrote:

On Thursday 21 April 2016 13:36:54 Guyren Howe wrote:

Anyone familiar with the issue would have to say that the tech world would
be a significantly better place if IBM had developed a real relational
database with an elegant query language rather than the awful camel of a
thing that is SQL.

If I had a few $million to spend in a philanthropical manner, I would hire
some of the best PG devs to develop a proper relational database server.
Probably a query language that expressed the relational algebra in a
scheme-like syntax, and the storage model would be properly relational (eg
no duplicate rows).

It's an enormous tragedy that all the development effort that has gone into
NoSQL database has pretty much all gotten it wrong: by all means throw out
SQL, but not the relational model with it. They're all just rehashing the
debate over hierarchical storage from the 70s. Comp Sci courses should
feature a history class.

It's a bit odd to me that someone isn't working on such a thing.

Just curious what folks here have to say…

Well when IBM were first developing relational databases there were two
different teams. One in California which produced System-R which became
what we now know as DB2 and spawned SQL, and the other in Peterlee in
the UK which was called PRTV (the Peterlee Relational Test Vehicle). PRTV
rather died but bits of it survived. In particular it was the first to system
to include a relational optimiser. You can find some details on the PRTV
page in Wikipedia.

It was written in PL/1, although it also used some modified microcode
and therefore some assembler.

It never appeared as a product, but there was a geographical system
which built on top of it which was if I recall corrected used by the Greater
London Council and Central Region Scotland, which did something of
what postgis does for PostgreSQL.

According to the Wikipedia page it did have a language (ISBL) but from what
I recall (and it was nearly 40 years ago) there were a series of PL/1
function calls we used rather than encoding the request as a string
as SQL systems require.

The IBM centre in Peterlee was closed, and the lab moved to Winchester
where I think it still resides.

One of the people involved in that was Hugh Darwen, who is one of the
authors of The Third Manifesto, which is an attempt to define what a
properly relational language and system should look like. So you could
say the experience of ISBL vs SQL has been folded into that effort.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

So, let's just flat-out ask.

Dear Important People: would the PostgreSQL project consider
supporting other query languages? Or creating a plug-in mechanism for
them, so that alternative interface languages could be added without
changing the base code?

On Thu, Apr 21, 2016 at 4:36 PM, Guyren Howe <guyren@gmail.com> wrote:

Anyone familiar with the issue would have to say that the tech world would be a significantly better place if IBM had developed a real relational database with an elegant query language rather than the awful camel of a thing that is SQL.

If I had a few $million to spend in a philanthropical manner, I would hire some of the best PG devs to develop a proper relational database server. Probably a query language that expressed the relational algebra in a scheme-like syntax, and the storage model would be properly relational (eg no duplicate rows).

It's an enormous tragedy that all the development effort that has gone into NoSQL database has pretty much all gotten it wrong: by all means throw out SQL, but not the relational model with it. They're all just rehashing the debate over hierarchical storage from the 70s. Comp Sci courses should feature a history class.

It's a bit odd to me that someone isn't working on such a thing.

Just curious what folks here have to say…

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

--
Ray Brinzer

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On 04/21/2016 01:36 PM, Guyren Howe wrote:

Anyone familiar with the issue would have to say that the tech world
would be a significantly better place if IBM had developed a real
relational database with an elegant query language

I'm surprised no one yet has mentioned Tutorial D by C. J. Date. His
book _Database in Depth_ is pretty much an extended argument for how
superior it is to SQL. RelDB is apparently an open source implementation
of it, and D4 is a commercial one. That's about all I know in terms of
practically using it for something. But Date & Tutorial D seems like a
good place to start if SQL isn't relational enough for you. The book I
mentioned is short and easy to read.

Paul

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Fri, Apr 22, 2016 at 12:25 PM, Raymond Brinzer <ray.brinzer@gmail.com>
wrote:

So, let's just flat-out ask.

Dear Important People: would the PostgreSQL project consider
supporting other query languages? Or creating a plug-in mechanism for
them, so that alternative interface languages could be added without
changing the base code?

​
If by important you mean possessing a commit-bit then I don't count...but
for me, such a project would have to gain significant adoption as a fork of
the PostgreSQL code base before it would ever be considered for take-over
by the mainline project.
​
​David J.​

The SQL language is terrible but we can live with it.

But the answer to "Are there any relational data stores that offer eventual consistency, easy distribution, schema-on-demand or any such things a large modern application can use?" appears to be no. And that's just awful.

On 04/22/2016 12:25 PM, Raymond Brinzer wrote:

So, let's just flat-out ask.

Dear Important People: would the PostgreSQL project consider
supporting other query languages? Or creating a plug-in mechanism for
them, so that alternative interface languages could be added without
changing the base code?

Probably not considering our mission.

JD

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Fri, Apr 22, 2016 at 12:54 PM, Guyren Howe <guyren@gmail.com> wrote:

The SQL language is terrible but we can live with it.

​If anything, and especially something as pervasive and esoteric as SQL,
makes you question your desire to live please get help.​

But the answer to "Are there any relational data stores that offer
eventual consistency, easy distribution, schema-on-demand or any such
things a large modern application can use?" appears to be no. And that's
just awful.

​The axiom "a bird in hand is worth two in the bush" comes to mind here.
This applies even if the bird-in-hand is ugly and the glimpses of the ones
in the bush indicates they are beautiful.

David J.

On Fri, Apr 22, 2016 at 3:07 PM, Paul Jungwirth
<pj@illuminatedcomputing.com> wrote:

I'm surprised no one yet has mentioned Tutorial D by C. J. Date. His book
_Database in Depth_ is pretty much an extended argument for how superior it
is to SQL. RelDB is apparently an open source implementation of it, and D4
is a commercial one. That's about all I know in terms of practically using
it for something. But Date & Tutorial D seems like a good place to start if
SQL isn't relational enough for you. The book I mentioned is short and easy
to read.

This is a relevant project: https://github.com/agentm/project-m36

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Andl is a "proper relational database" language.

Andl is an original implementation of the language D described in The Third Manifesto. http://www.dcs.warwick.ac.uk/~hugh/TTM/.

I have a working implementation of Andl on Postgres. See http://www.andl.org/2016/04/postgres-meet-andl/. This version is not ready for release, but there is a download that supports Sqlite, Thrift and REST.

The syntax of Andl is quite different from Tutorial D, or SQL. It does what SQL does, including any relational query you can think of, and a few you haven't! Check out the web site for some code samples.

Regards
David M Bennett FACS

Andl - A New Database Language - andl.org

-----Original Message-----
From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-
owner@postgresql.org] On Behalf Of Paul Jungwirth
Sent: Saturday, 23 April 2016 5:38 AM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Proper relational database?

On 04/21/2016 01:36 PM, Guyren Howe wrote:

Anyone familiar with the issue would have to say that the tech world
would be a significantly better place if IBM had developed a real >

relational database with an elegant query language

I'm surprised no one yet has mentioned Tutorial D by C. J. Date. His book
_Database in Depth_ is pretty much an extended argument for how superior it
is to SQL. RelDB is apparently an open source implementation of it, and D4 is
a commercial one. That's about all I know in terms of practically using it
for something. But Date & Tutorial D seems like a good place to start if SQL
isn't relational enough for you. The book I mentioned is short and easy to
read.

Paul

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make
changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general