On Sat, Jul 06, 2013 at 11:49:21AM +0100, Dean Rasheed wrote:
> On 5 July 2013 18:23, David Fetter wrote:
> > Please find attached changes based on the above.
> >
>
> This looks good. The grammar changes are smaller and neater now on top
> of the makeFuncCall() patch.
>
> Overall I think this pa
On 5 July 2013 18:23, David Fetter wrote:
> Please find attached changes based on the above.
>
This looks good. The grammar changes are smaller and neater now on top
of the makeFuncCall() patch.
Overall I think this patch offers useful additional functionality, in
compliance with the SQL spec, w
On Mon, Jul 01, 2013 at 05:30:38PM +0100, Dean Rasheed wrote:
> On 1 July 2013 01:44, David Fetter wrote:
> > On Fri, Jun 28, 2013 at 09:22:52PM +0100, Dean Rasheed wrote:
> >> On 21 June 2013 06:16, David Fetter wrote:
> >> > Please find attached a patch which allows subqueries in the FILTER
> >
On Mon, Jul 1, 2013 at 3:19 AM, Jeevan Chalke
wrote:
> I have re-validated this new patch and it looks good to go in now.
>
> I saw that it's already marked ready for committer.
I don't normally like to commit things over another committer's
objections, but this has +1 votes from four other commi
On 1 July 2013 01:44, David Fetter wrote:
> On Fri, Jun 28, 2013 at 09:22:52PM +0100, Dean Rasheed wrote:
>> On 21 June 2013 06:16, David Fetter wrote:
>> > Please find attached a patch which allows subqueries in the FILTER
>> > clause and adds regression testing for same.
>> >
>>
>> This needs r
On Mon, Jul 1, 2013 at 6:16 AM, David Fetter wrote:
> On Fri, Jun 28, 2013 at 01:28:35PM -0400, Peter Eisentraut wrote:
> > On 6/28/13 11:30 AM, Robert Haas wrote:
> > > On Fri, Jun 28, 2013 at 10:31 AM, Tom Lane wrote:
> > >> David Fetter writes:
> > >>> Please find attached the latest patch.
On Fri, Jun 28, 2013 at 01:28:35PM -0400, Peter Eisentraut wrote:
> On 6/28/13 11:30 AM, Robert Haas wrote:
> > On Fri, Jun 28, 2013 at 10:31 AM, Tom Lane wrote:
> >> David Fetter writes:
> >>> Please find attached the latest patch.
> >>
> >> I remain of the opinion that this is simply a bad idea
On Fri, Jun 28, 2013 at 09:22:52PM +0100, Dean Rasheed wrote:
> On 21 June 2013 06:16, David Fetter wrote:
> > Please find attached a patch which allows subqueries in the FILTER
> > clause and adds regression testing for same.
> >
>
> This needs re-basing/merging following Robert's recent commit
On 21 June 2013 06:16, David Fetter wrote:
> Please find attached a patch which allows subqueries in the FILTER
> clause and adds regression testing for same.
>
This needs re-basing/merging following Robert's recent commit to make
OVER unreserved.
Regards,
Dean
--
Sent via pgsql-hackers maili
On 6/28/13 11:30 AM, Robert Haas wrote:
> On Fri, Jun 28, 2013 at 10:31 AM, Tom Lane wrote:
>> David Fetter writes:
>>> Please find attached the latest patch.
>>
>> I remain of the opinion that this is simply a bad idea. It is unlike
>> our habits for constructing other types of nodes, and makes
On Fri, Jun 28, 2013 at 10:31 AM, Tom Lane wrote:
> David Fetter writes:
>> Please find attached the latest patch.
>
> I remain of the opinion that this is simply a bad idea. It is unlike
> our habits for constructing other types of nodes, and makes it harder
> not easier to find all the places
On Fri, Jun 28, 2013 at 10:31:16AM -0400, Tom Lane wrote:
> David Fetter writes:
> > Please find attached the latest patch.
>
> I remain of the opinion that this is simply a bad idea. It is unlike
> our habits for constructing other types of nodes, and makes it harder
> not easier to find all th
David Fetter writes:
> Please find attached the latest patch.
I remain of the opinion that this is simply a bad idea. It is unlike
our habits for constructing other types of nodes, and makes it harder
not easier to find all the places that need to be updated when adding
another field to FuncCall
On Tue, Jun 25, 2013 at 02:54:55PM +0530, Jeevan Chalke wrote:
> On Tue, Jun 25, 2013 at 11:11 AM, Jeevan Chalke <
> jeevan.cha...@enterprisedb.com> wrote:
>
> > Hi David,
> >
> > I hope this is the latest patch to review, right ?
> >
> > I am going to review it.
> >
> > I have gone through the di
On 6/23/13 10:50 PM, Tom Lane wrote:
> It'd sure be interesting to know what the SQL committee's target parsing
> algorithm is.
It's whatever Oracle and IBM implement.
> Or maybe they really don't give a damn about breaking
> applications every time they invent a new reserved word?
Well, yes, I
2013/6/26 Dean Rasheed :
> On 26 June 2013 01:01, Josh Berkus wrote:
>>
>>> I know it's heresy in these parts, but maybe we should consider
>>> adopting a non-spec syntax for this feature? In particular, it's
>>> really un-obvious why the FILTER clause shouldn't be inside rather
>>> than outside
On 26 June 2013 01:01, Josh Berkus wrote:
>
>> I know it's heresy in these parts, but maybe we should consider
>> adopting a non-spec syntax for this feature? In particular, it's
>> really un-obvious why the FILTER clause shouldn't be inside rather
>> than outside the aggregate's parens, like ORD
> I know it's heresy in these parts, but maybe we should consider
> adopting a non-spec syntax for this feature? In particular, it's
> really un-obvious why the FILTER clause shouldn't be inside rather
> than outside the aggregate's parens, like ORDER BY.
Well, what other DBMSes support this fea
On Sun, Jun 23, 2013 at 10:50 PM, Tom Lane wrote:
> David Fetter writes:
>> On Sun, Jun 23, 2013 at 07:44:26AM -0700, Kevin Grittner wrote:
>>> I think it is OK if that gets a syntax error. If that's the "worst
>>> case" I like this approach.
>
>> I think reducing the usefulness of error message
2013/6/25 Tom Lane :
> Dean Rasheed writes:
>> On 24 June 2013 03:50, Tom Lane wrote:
>>> Going on the same principle, we could probably let FILTER be an
>>> unreserved keyword while FILTER_FOLLOWED_BY_PAREN could be a
>>> type_func_name_keyword. (I've not tried this though.)
>
>> I've not tried
Dean Rasheed writes:
> On 24 June 2013 03:50, Tom Lane wrote:
>> Going on the same principle, we could probably let FILTER be an
>> unreserved keyword while FILTER_FOLLOWED_BY_PAREN could be a
>> type_func_name_keyword. (I've not tried this though.)
> I've not tried either, but wouldn't that me
On 24 June 2013 03:50, Tom Lane wrote:
> David Fetter writes:
>> On Sun, Jun 23, 2013 at 07:44:26AM -0700, Kevin Grittner wrote:
>>> I think it is OK if that gets a syntax error. If that's the "worst
>>> case" I like this approach.
>
>> I think reducing the usefulness of error messages is someth
On Tue, Jun 25, 2013 at 11:11 AM, Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
> Hi David,
>
> I hope this is the latest patch to review, right ?
>
> I am going to review it.
>
> I have gone through the discussion on this thread and I agree with Stephen
> Frost that it don't add much imp
Hi David,
I hope this is the latest patch to review, right ?
I am going to review it.
I have gone through the discussion on this thread and I agree with Stephen
Frost that it don't add much improvements as such but definitely it is
going to be easy for contributors in this area as they don't nee
David Fetter writes:
> On Sun, Jun 23, 2013 at 07:44:26AM -0700, Kevin Grittner wrote:
>> I think it is OK if that gets a syntax error. If that's the "worst
>> case" I like this approach.
> I think reducing the usefulness of error messages is something we need
> to think extremely hard about bef
On Sun, Jun 23, 2013 at 07:44:26AM -0700, Kevin Grittner wrote:
> Dean Rasheed wrote:
>
> > I'm still not happy that this patch is making FILTER a new reserved
> > keyword, because I think it is a common enough English word (and an
> > obscure enough SQL keyword) that people may well have used it
Dean Rasheed wrote:
> I'm still not happy that this patch is making FILTER a new reserved
> keyword, because I think it is a common enough English word (and an
> obscure enough SQL keyword) that people may well have used it for
> table names or aliases, and so their code will break.
Well, if it
On 21 June 2013 10:02, Dean Rasheed wrote:
> On 21 June 2013 06:16, David Fetter wrote:
>> On Fri, Jun 21, 2013 at 12:10:25AM -0400, Alvaro Herrera wrote:
>>> David Fetter escribió:
>>> > On Thu, Jun 20, 2013 at 08:59:27PM +0100, Dean Rasheed wrote:
>>>
>>> > > In my testing of sub-queries in the
On 21 June 2013 06:16, David Fetter wrote:
> On Fri, Jun 21, 2013 at 12:10:25AM -0400, Alvaro Herrera wrote:
>> David Fetter escribió:
>> > On Thu, Jun 20, 2013 at 08:59:27PM +0100, Dean Rasheed wrote:
>>
>> > > In my testing of sub-queries in the FILTER clause (an extension to the
>> > > spec), I
On 21 June 2013 05:01, David Fetter wrote:
> What tests do you think should be there that aren't?
>
I think I expected to see more tests related to some of the specific
code changes, such as
CREATE TABLE t AS SELECT * FROM generate_series(1,10) t(x);
-- Should fail (filter can't be used for non
On Fri, Jun 21, 2013 at 12:10:25AM -0400, Alvaro Herrera wrote:
> David Fetter escribió:
> > On Thu, Jun 20, 2013 at 08:59:27PM +0100, Dean Rasheed wrote:
>
> > > In my testing of sub-queries in the FILTER clause (an extension to the
> > > spec), I was able to produce the following error:
> >
> >
On Fri, Jun 21, 2013 at 12:10:25AM -0400, Alvaro Herrera wrote:
> David Fetter escribió:
> > On Thu, Jun 20, 2013 at 08:59:27PM +0100, Dean Rasheed wrote:
>
> > > In my testing of sub-queries in the FILTER clause (an extension
> > > to the spec), I was able to produce the following error:
> >
> >
David Fetter escribió:
> On Thu, Jun 20, 2013 at 08:59:27PM +0100, Dean Rasheed wrote:
> > In my testing of sub-queries in the FILTER clause (an extension to the
> > spec), I was able to produce the following error:
>
> Per the spec,
>
> B) A shall not contain a , a function>, or an outer ref
On Thu, Jun 20, 2013 at 08:59:27PM +0100, Dean Rasheed wrote:
> On 17 June 2013 06:36, David Fetter wrote:
> >> > > Please find attached two versions of a patch which provides optional
> >> > > FILTER clause for aggregates (T612, "Advanced OLAP operations").
> >> > >
> >> > > The first is intended
On 17 June 2013 06:36, David Fetter wrote:
>> > > Please find attached two versions of a patch which provides optional
>> > > FILTER clause for aggregates (T612, "Advanced OLAP operations").
>> > >
>> > > The first is intended to be applied on top of the previous patch, the
>> > > second without i
* David Fetter (da...@fetter.org) wrote:
> On Mon, Feb 11, 2013 at 10:48:38AM -0800, David Fetter wrote:
> > On Sun, Feb 10, 2013 at 10:09:19AM -0500, Tom Lane wrote:
> > > David Fetter writes:
> > > > Per suggestions and lots of help from Andrew Gierth, please find
> > > > attached a patch to cle
On Mon, Feb 11, 2013 at 10:48:38AM -0800, David Fetter wrote:
> On Sun, Feb 10, 2013 at 10:09:19AM -0500, Tom Lane wrote:
> > David Fetter writes:
> > > Per suggestions and lots of help from Andrew Gierth, please find
> > > attached a patch to clean up the call sites for FuncCall nodes, which
> >
On Sun, Apr 28, 2013 at 01:29:41PM -0700, David Fetter wrote:
> On Tue, Feb 26, 2013 at 01:09:30PM -0800, David Fetter wrote:
> > On Wed, Feb 13, 2013 at 06:45:31AM -0800, David Fetter wrote:
> > > On Sat, Feb 09, 2013 at 11:59:22PM -0800, David Fetter wrote:
> > > > Folks,
> > > >
> > > > Per sug
On Tue, Feb 26, 2013 at 01:09:30PM -0800, David Fetter wrote:
> On Wed, Feb 13, 2013 at 06:45:31AM -0800, David Fetter wrote:
> > On Sat, Feb 09, 2013 at 11:59:22PM -0800, David Fetter wrote:
> > > Folks,
> > >
> > > Per suggestions and lots of help from Andrew Gierth, please find
> > > attached a
On Wed, Feb 13, 2013 at 06:45:31AM -0800, David Fetter wrote:
> On Sat, Feb 09, 2013 at 11:59:22PM -0800, David Fetter wrote:
> > Folks,
> >
> > Per suggestions and lots of help from Andrew Gierth, please find
> > attached a patch to clean up the call sites for FuncCall nodes, which
> > I'd like t
On Wed, Feb 13, 2013 at 06:45:31AM -0800, David Fetter wrote:
> On Sat, Feb 09, 2013 at 11:59:22PM -0800, David Fetter wrote:
> > Folks,
> >
> > Per suggestions and lots of help from Andrew Gierth, please find
> > attached a patch to clean up the call sites for FuncCall nodes, which
> > I'd like t
On Sun, Feb 10, 2013 at 10:09:19AM -0500, Tom Lane wrote:
> David Fetter writes:
> > Per suggestions and lots of help from Andrew Gierth, please find
> > attached a patch to clean up the call sites for FuncCall nodes, which
> > I'd like to expand centrally rather than in each of the 37 (or 38, but
On Sun, Feb 10, 2013 at 10:09:19AM -0500, Tom Lane wrote:
> David Fetter writes:
> > Per suggestions and lots of help from Andrew Gierth, please find
> > attached a patch to clean up the call sites for FuncCall nodes, which
> > I'd like to expand centrally rather than in each of the 37 (or 38, but
David Fetter writes:
> Per suggestions and lots of help from Andrew Gierth, please find
> attached a patch to clean up the call sites for FuncCall nodes, which
> I'd like to expand centrally rather than in each of the 37 (or 38, but
> I only redid 37) places where it's called. The remaining one i
Folks,
Per suggestions and lots of help from Andrew Gierth, please find
attached a patch to clean up the call sites for FuncCall nodes, which
I'd like to expand centrally rather than in each of the 37 (or 38, but
I only redid 37) places where it's called. The remaining one is in
src/backend/nodes
45 matches
Mail list logo
