Re: mixed, named notation support - Mailing list pgsql-hackers

From Robert Haas
Subject Re: mixed, named notation support
Date
Msg-id 603c8f070908061912o2556dc70y2da5811e2f0d7f53@mail.gmail.com
Whole thread Raw
In response to Re: mixed, named notation support  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: mixed, named notation support  (Steve Prentice <prentice@cisco.com>)
Re: mixed, named notation support  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: mixed, named notation support  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Aug 6, 2009 at 7:10 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Bernd Helmle <mailings@oopsware.de> writes:
>> Here again a patch version with updated documentation. I will stop
>> reviewing this patch now and mark this ready for committer, so we have some
>> time left to incorporate additional feedback.
>
> I'm starting to look at this now, and my very first reaction was
> "what in the world is a leaky list?".  I'm not sure I like the
> data structure itself, but the terminology is certainly completely
> unhelpful.  Can't you come up with something better than
> "continuous/leaky"?

Stepping back a bit, are we sure this is a feature we even want to
support?  It was already pointed out in the thread on "Parser's hook
based on funccall" that SQL:201x may standardize => for this purpose.
I realize that's a problem because of the possibility of a
user-defined operator named =>, but aren't we usually reluctant to
adopt syntax that is thought likely to be incompatible with current or
future SQL standards?

http://archives.postgresql.org/pgsql-hackers/2009-07/msg01715.php

...Robert


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: machine-readable explain output v4
Next
From: Alvaro Herrera
Date:
Subject: Re: docs: mention autovacuum when ANALYZE is recommended