On 9/9/16 2:57 PM, Peter Eisentraut wrote:
> On 6/6/16 9:59 AM, Merlin Moncure wrote:
>> Thanks for the review. All your comments look pretty reasonable. I'll
>> touch it up and resubmit.
>
> This is the last email in this thread that the commit fest app shows. I
> think we are waiting on an upd
On 6/6/16 9:59 AM, Merlin Moncure wrote:
> Thanks for the review. All your comments look pretty reasonable. I'll
> touch it up and resubmit.
This is the last email in this thread that the commit fest app shows. I
think we are waiting on an updated patch, with docs and tests.
--
Peter Eisentrau
On Sat, Jun 4, 2016 at 10:45 PM, David G. Johnston
wrote:
> On Tuesday, March 22, 2016, Merlin Moncure wrote:
>>
>>
>> Anyways, here's the patch with documentation adjustments as promised.
>> I ended up keeping the 'without result' section because it contained
>> useful information about plan cac
2016-06-05 5:45 GMT+02:00 David G. Johnston :
> On Tuesday, March 22, 2016, Merlin Moncure wrote:
>
>>
>> Anyways, here's the patch with documentation adjustments as promised.
>> I ended up keeping the 'without result' section because it contained
>> useful information about plan caching,
>>
>> m
On Tue, 22 Mar 2016 at 10:34 Robert Haas wrote:
> Yeah, I think requiring PERFORM is stupid and annoying. +1 for
> letting people write a SELECT with no target.
>
Apologies for being late on the thread, but another +1 from me. I've often
been frustrated by the dissonance of PERFORM against SQL
On Tuesday, March 22, 2016, Merlin Moncure wrote:
>
> Anyways, here's the patch with documentation adjustments as promised.
> I ended up keeping the 'without result' section because it contained
> useful information about plan caching,
>
> merlin
>
> diff --git a/doc/src/sgml/plpgsql.sgml b/doc/s
2016-04-11 15:37 GMT+02:00 Merlin Moncure :
> On Sun, Apr 10, 2016 at 3:13 AM, Pavel Stehule
> wrote:
> >
> > Hi
> >
> > 2016-03-21 22:13 GMT+01:00 Pavel Stehule :
> >>
> >> Hi
> >>
> >> 2016-03-21 21:24 GMT+01:00 Merlin Moncure :
> >>>
> >>> Patch is trivial (see below), discussion is not :-).
>
On Sun, Apr 10, 2016 at 3:13 AM, Pavel Stehule wrote:
>
> Hi
>
> 2016-03-21 22:13 GMT+01:00 Pavel Stehule :
>>
>> Hi
>>
>> 2016-03-21 21:24 GMT+01:00 Merlin Moncure :
>>>
>>> Patch is trivial (see below), discussion is not :-).
>>>
>>> I see no useful reason to require INTO when returning data wit
On Sun, Apr 10, 2016 at 10:01 AM, Pavel Stehule
wrote:
>
>
> 2016-04-10 18:49 GMT+02:00 David G. Johnston :
>
>> On Sun, Apr 10, 2016 at 9:16 AM, Pavel Stehule
>> wrote:
>>
>>>
>>>
>>> 2016-04-10 17:49 GMT+02:00 David G. Johnston >> >:
>>>
On Sun, Apr 10, 2016 at 1:13 AM, Pavel Stehule >>>
2016-04-10 18:49 GMT+02:00 David G. Johnston :
> On Sun, Apr 10, 2016 at 9:16 AM, Pavel Stehule
> wrote:
>
>>
>>
>> 2016-04-10 17:49 GMT+02:00 David G. Johnston
>> :
>>
>>> On Sun, Apr 10, 2016 at 1:13 AM, Pavel Stehule
>>> wrote:
>>>
Hi
2016-03-21 22:13 GMT+01:00 Pavel Stehule :
On Sun, Apr 10, 2016 at 9:16 AM, Pavel Stehule
wrote:
>
>
> 2016-04-10 17:49 GMT+02:00 David G. Johnston :
>
>> On Sun, Apr 10, 2016 at 1:13 AM, Pavel Stehule
>> wrote:
>>
>>> Hi
>>>
>>> 2016-03-21 22:13 GMT+01:00 Pavel Stehule :
>>>
Hi
2016-03-21 21:24 GMT+01:00 Merlin Moncure :
2016-04-10 17:49 GMT+02:00 David G. Johnston :
> On Sun, Apr 10, 2016 at 1:13 AM, Pavel Stehule
> wrote:
>
>> Hi
>>
>> 2016-03-21 22:13 GMT+01:00 Pavel Stehule :
>>
>>> Hi
>>>
>>> 2016-03-21 21:24 GMT+01:00 Merlin Moncure :
>>>
Patch is trivial (see below), discussion is not :-).
I
On Sun, Apr 10, 2016 at 1:13 AM, Pavel Stehule
wrote:
> Hi
>
> 2016-03-21 22:13 GMT+01:00 Pavel Stehule :
>
>> Hi
>>
>> 2016-03-21 21:24 GMT+01:00 Merlin Moncure :
>>
>>> Patch is trivial (see below), discussion is not :-).
>>>
>>> I see no useful reason to require INTO when returning data with
>
Hi
2016-03-21 22:13 GMT+01:00 Pavel Stehule :
> Hi
>
> 2016-03-21 21:24 GMT+01:00 Merlin Moncure :
>
>> Patch is trivial (see below), discussion is not :-).
>>
>> I see no useful reason to require INTO when returning data with
>> SELECT. However, requiring queries to indicate not needing data vi
On Wed, Mar 23, 2016 at 10:57 AM, Jim Nasby wrote:
> On 3/22/16 8:37 AM, Merlin Moncure wrote:
>>>
>>> I afraid of useless and forgotten call of functions. But the risk is same
>>> >like PERFORM - so this is valid from one half. The PERFORM statement
>>> > holds
>>> >special semantic, and it is in
On 3/22/16 8:37 AM, Merlin Moncure wrote:
I afraid of useless and forgotten call of functions. But the risk is same
>like PERFORM - so this is valid from one half. The PERFORM statement holds
>special semantic, and it is interesting.
I see your point here, but the cost of doing that far outweigh
On Tue, Mar 22, 2016 at 12:20 AM, Pavel Stehule wrote:
>
> 2016-03-22 6:06 GMT+01:00 Tom Lane :
>>
>> Pavel Stehule writes:
>> > I can live with SELECT fx(x). It is little bit dangerous, but this risk
>> > can
>> > be easy detected by plpgsql_check.
>>
>> Dangerous how?
>
> I afraid of useless an
2016-03-22 6:06 GMT+01:00 Tom Lane :
> Pavel Stehule writes:
> > I can live with SELECT fx(x). It is little bit dangerous, but this risk
> can
> > be easy detected by plpgsql_check.
>
> Dangerous how?
>
I afraid of useless and forgotten call of functions. But the risk is same
like PERFORM - so t
Pavel Stehule writes:
> I can live with SELECT fx(x). It is little bit dangerous, but this risk can
> be easy detected by plpgsql_check.
Dangerous how?
>> So, I'm -1 on not having any keyword at all. I have no objection
>> to Merlin's proposal though. I agree that PERFORM is starting to
>> loo
2016-03-21 23:49 GMT+01:00 Tom Lane :
> Jim Nasby writes:
> > On 3/21/16 5:03 PM, Merlin Moncure wrote:
> >> in Oracle, you'd simply do:
> >> LogIt('I did something');
>
> > It would be *great* if we could support that in plpgsql.
>
> FWIW, I'm hesitant to just start accepting that syntax as if i
2016-03-21 23:26 GMT+01:00 Jim Nasby :
> On 3/21/16 5:03 PM, Merlin Moncure wrote:
>
>> in Oracle, you'd simply do:
>> LogIt('I did something');
>>
>
> It would be *great* if we could support that in plpgsql.
>
> I'm not sure what Oracle does for SELECT statements without INTO/BULK
>> UPDATE. I'm
2016-03-21 23:03 GMT+01:00 Merlin Moncure :
> On Mon, Mar 21, 2016 at 4:13 PM, Pavel Stehule
> wrote:
> > Hi
> >
> > 2016-03-21 21:24 GMT+01:00 Merlin Moncure :
> >>
> >> Patch is trivial (see below), discussion is not :-).
> >>
> >> I see no useful reason to require INTO when returning data with
On Mon, Mar 21, 2016 at 6:49 PM, Tom Lane wrote:
> So, I'm -1 on not having any keyword at all. I have no objection
> to Merlin's proposal though. I agree that PERFORM is starting to
> look a bit silly, since it doesn't play with WITH for instance.
Yeah, I think requiring PERFORM is stupid and
On Mon, Mar 21, 2016 at 5:49 PM, Tom Lane wrote:
> So, I'm -1 on not having any keyword at all. I have no objection
> to Merlin's proposal though. I agree that PERFORM is starting to
> look a bit silly, since it doesn't play with WITH for instance.
All right -- I'll submit a revised patch with
Jim Nasby writes:
> On 3/21/16 5:03 PM, Merlin Moncure wrote:
>> in Oracle, you'd simply do:
>> LogIt('I did something');
> It would be *great* if we could support that in plpgsql.
FWIW, I'm hesitant to just start accepting that syntax as if it were an
equivalent to "SELECT f(x)" or "PERFORM f(x
On 3/21/16 5:03 PM, Merlin Moncure wrote:
in Oracle, you'd simply do:
LogIt('I did something');
It would be *great* if we could support that in plpgsql.
I'm not sure what Oracle does for SELECT statements without INTO/BULK
UPDATE. I'm not really inclined to care -- I'm really curious to see
On Mon, Mar 21, 2016 at 4:13 PM, Pavel Stehule wrote:
> Hi
>
> 2016-03-21 21:24 GMT+01:00 Merlin Moncure :
>>
>> Patch is trivial (see below), discussion is not :-).
>>
>> I see no useful reason to require INTO when returning data with
>> SELECT. However, requiring queries to indicate not needing
Hi
2016-03-21 21:24 GMT+01:00 Merlin Moncure :
> Patch is trivial (see below), discussion is not :-).
>
> I see no useful reason to require INTO when returning data with
> SELECT. However, requiring queries to indicate not needing data via
> PERFORM causes some annoyances:
>
> *) converting rout
Patch is trivial (see below), discussion is not :-).
I see no useful reason to require INTO when returning data with
SELECT. However, requiring queries to indicate not needing data via
PERFORM causes some annoyances:
*) converting routines back and forth between pl/pgsql and pl/sql
requires need
29 matches
Mail list logo