On 2011-02-28 8:20 AM +0200, Tom Lane wrote:
Marko Tiikkaja writes:
On 2011-02-24 6:40 PM, I wrote:
I am planning on working on the documentation this weekend.
And here's my attempt. The language is a bit poor at some places but I
can't think of anything better.
Applied after some rather
Marko Tiikkaja writes:
> On 2011-02-24 6:40 PM, I wrote:
>> I am planning on working on the documentation this weekend.
> And here's my attempt. The language is a bit poor at some places but I
> can't think of anything better.
Applied after some rather heavy editorialization.
> I tried to be
Marko Tiikkaja writes:
> On 2011-02-24 6:40 PM, I wrote:
>> I am planning on working on the documentation this weekend.
> And here's my attempt. The language is a bit poor at some places but I
> can't think of anything better.
Thanks, will work on this next.
regards, t
On 2011-02-24 6:40 PM, I wrote:
I am planning on working on the documentation this weekend.
And here's my attempt. The language is a bit poor at some places but I
can't think of anything better.
I tried to be more strict about using "subquery" when talking about
WITHs in general since INSE
On Sat, Feb 26, 2011 at 12:52:40AM -0500, Robert Haas wrote:
> On Sat, Feb 26, 2011 at 12:30 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> Yay! I'm excited about this, particularly the possible "pipelining"
> >> stuff, where you can do WITH (DELETE .. RETURNING ..) INSERT ... and
> >> have i
On 2011-02-26 4:41 AM +0200, Tom Lane wrote:
Marko Tiikkaja writes:
One thing bothers me though: what was the reason for requiring a
RETURNING clause for data-modifying statements in WITH?
That test was in your patch, no? I moved the code to another place
but it's still enforcing the same th
On Sat, Feb 26, 2011 at 12:30 AM, Tom Lane wrote:
> Robert Haas writes:
>> Yay! I'm excited about this, particularly the possible "pipelining"
>> stuff, where you can do WITH (DELETE .. RETURNING ..) INSERT ... and
>> have it be like cool and fast and stuff.
>
>> Or at least I hope you can do t
Robert Haas writes:
> Yay! I'm excited about this, particularly the possible "pipelining"
> stuff, where you can do WITH (DELETE .. RETURNING ..) INSERT ... and
> have it be like cool and fast and stuff.
> Or at least I hope you can do that.
It's gonna need some work yet. As things stand, the
On Fri, Feb 25, 2011 at 7:00 PM, Tom Lane wrote:
> Marko Tiikkaja writes:
>> On 2011-02-24 6:37 PM +0200, Tom Lane wrote:
>>> OK, I will make those adjustments. Are you going to do more work on the
>>> documentation part of the patch? I can stick to working on the code
>>> part meanwhile, if yo
On Thu, Feb 24, 2011 at 11:35:30AM -0800, David Wheeler wrote:
> On Feb 24, 2011, at 10:43 AM, Robert Haas wrote:
>
> >> The best idea I have at the moment is to spell out "data modifying
> >> command" (or "statement") rather than relying on the acronym.
> >> In the code, we could change hasDmlWit
On Thu, Feb 24, 2011 at 11:20:48AM -0500, Tom Lane wrote:
> The wCTE patch refers to the feature it's adding as "DML WITH". I'm
> still pretty unhappy with that terminology. In my view of the world,
> "DML" includes SELECT as well as INSERT/UPDATE/DELETE. The wikipedia
> entry about the term
> h
Marko Tiikkaja writes:
> On 2011-02-26 2:00 AM, Tom Lane wrote:
>> I've gone ahead and applied the code portion of the patch, with
>> modifications as per discussion, and other editorialization.
> Thanks a lot!
> One thing bothers me though: what was the reason for requiring a
> RETURNING claus
On 2011-02-26 2:00 AM, Tom Lane wrote:
I've gone ahead and applied the code portion of the patch, with
modifications as per discussion, and other editorialization.
Thanks a lot!
One thing bothers me though: what was the reason for requiring a
RETURNING clause for data-modifying statements in
Marko Tiikkaja writes:
> On 2011-02-24 6:37 PM +0200, Tom Lane wrote:
>> OK, I will make those adjustments. Are you going to do more work on the
>> documentation part of the patch? I can stick to working on the code
>> part meanwhile, if you are.
> I am planning on working on the documentation
On Feb 24, 2011, at 10:43 AM, Robert Haas wrote:
>> The best idea I have at the moment is to spell out "data modifying
>> command" (or "statement") rather than relying on the acronym.
>> In the code, we could change hasDmlWith to hasModifyingWith, for
>> example. The error messages could read lik
On Thu, Feb 24, 2011 at 11:20 AM, Tom Lane wrote:
> The wCTE patch refers to the feature it's adding as "DML WITH". I'm
> still pretty unhappy with that terminology. In my view of the world,
> "DML" includes SELECT as well as INSERT/UPDATE/DELETE. The wikipedia
> entry about the term
> http://e
On 02/24/2011 11:20 AM, Tom Lane wrote:
The wCTE patch refers to the feature it's adding as "DML WITH". I'm
still pretty unhappy with that terminology. In my view of the world,
"DML" includes SELECT as well as INSERT/UPDATE/DELETE. The wikipedia
entry about the term
http://en.wikipedia.org/w
On 2011-02-24 6:37 PM +0200, Tom Lane wrote:
OK, I will make those adjustments. Are you going to do more work on the
documentation part of the patch? I can stick to working on the code
part meanwhile, if you are.
I am planning on working on the documentation this weekend.
Regards,
Marko Tii
Marko Tiikkaja writes:
> On 2011-02-24 6:20 PM +0200, Tom Lane wrote:
>> The best idea I have at the moment is to spell out "data modifying
>> command" (or "statement") rather than relying on the acronym.
>> In the code, we could change hasDmlWith to hasModifyingWith, for
>> example. The error me
On 2011-02-24 6:20 PM +0200, Tom Lane wrote:
The wCTE patch refers to the feature it's adding as "DML WITH". I'm
still pretty unhappy with that terminology. In my view of the world,
"DML" includes SELECT as well as INSERT/UPDATE/DELETE. The wikipedia
entry about the term
http://en.wikipedia.or
The wCTE patch refers to the feature it's adding as "DML WITH". I'm
still pretty unhappy with that terminology. In my view of the world,
"DML" includes SELECT as well as INSERT/UPDATE/DELETE. The wikipedia
entry about the term
http://en.wikipedia.org/wiki/Data_Manipulation_Language
agrees that t
21 matches
Mail list logo
