On Tue, Feb 9, 2010 at 3:13 PM, Marko Tiikkaja
wrote:
> On 2010-02-08 18:42 +0200, Robert Haas wrote:
>> On Thu, Feb 4, 2010 at 11:57 AM, Marko Tiikkaja
>> wrote:
>>> Here's an updated patch. Only changes from the previous patch are
>>> fixing the above issue and a regression test for it.
>>
>>
On 2010-02-08 18:42 +0200, Robert Haas wrote:
> On Thu, Feb 4, 2010 at 11:57 AM, Marko Tiikkaja
> wrote:
>> Here's an updated patch. Only changes from the previous patch are
>> fixing the above issue and a regression test for it.
>
> - I'm not sure that canSetTag is the right name for the additi
On Mon, Feb 8, 2010 at 3:30 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Mon, Feb 8, 2010 at 1:01 PM, Marko Tiikkaja
>> wrote:
>> >> Could we just write, e.g.
>> >> "non-SELECT statements are not allowed within a cursor declaration?"
>> >> Or we could say "INSERT, UPDATE, and DELETE st
Robert Haas escribió:
> On Mon, Feb 8, 2010 at 1:01 PM, Marko Tiikkaja
> wrote:
> >> Could we just write, e.g.
> >> "non-SELECT statements are not allowed within a cursor declaration?"
> >> Or we could say "INSERT, UPDATE, and DELETE statements are not allowed
> >> within a cursor declaration", bu
Robert Haas escribió:
> Yeah, I don't feel good about "INSERT, UPDATE, and DELETE" because in
> most of the relevant contexts the list might get longer if in the
> future we allow things like EXPLAIN and COPY within CTEs. I think
> "Non-SELECT statement" is reasonably clear, though; people might
On Mon, Feb 8, 2010 at 1:01 PM, Marko Tiikkaja
wrote:
>> Could we just write, e.g.
>> "non-SELECT statements are not allowed within a cursor declaration?"
>> Or we could say "INSERT, UPDATE, and DELETE statements are not allowed
>> within a cursor declaration", but I'm thinking we may want to allo
On 2010-02-08 18:42 +0200, Robert Haas wrote:
> On Thu, Feb 4, 2010 at 11:57 AM, Marko Tiikkaja
>> Here's an updated patch. Only changes from the previous patch are
>> fixing the above issue and a regression test for it.
>
> - I'm not sure that canSetTag is the right name for the additional
> arg
On Thu, Feb 4, 2010 at 11:57 AM, Marko Tiikkaja
wrote:
> On 2010-02-04 18:04 UTC+2, I wrote:
>> While working on the docs, I noticed one problem with the patch itself:
>> it doesn't handle multi-statement DO INSTEAD rules correctly. I'm going
>> to submit a fix for that later.
>
> Here's an updat
Takahiro Itagaki writes:
> * In the regression tests, almost all of them don't have ORDER BY clause.
> They just work, but we might need ORDER BY to get robust output.
> What did we do in other regression tests?
We add ORDER BY only when experience shows it's necessary. The
reasoning is expl
On 2010-02-05 07:14 UTC+2, Takahiro Itagaki wrote:
>
> Marko Tiikkaja wrote:
>
>> Here's an updated patch. Only changes from the previous patch are
>> fixing the above issue and a regression test for it.
>
> * In the regression tests, almost all of them don't have ORDER BY clause.
> They jus
Marko Tiikkaja wrote:
> Here's an updated patch. Only changes from the previous patch are
> fixing the above issue and a regression test for it.
A brief report for of the patch:
* The patch has the following error cases, and also have one regression
test for each case.
- DML WITH is not a
11 matches
Mail list logo
