On Tue, Mar 20, 2018 at 4:19 PM, Merlin Moncure wrote:
> A) you can't assign output variables with into:
> CALL p(1) INTO i; // gives syntax error
>
> B) you can't assign via assignment
> i := p(1); // gives error, 'use CALL'
>
> C) but you *can* via execute
> EXECUTE 'CALL p(1)' INTO i; // this
On Tue, Mar 20, 2018 at 10:09 AM, Pavel Stehule wrote:
> 2018-03-20 15:18 GMT+01:00 Merlin Moncure :
>> >> postgres=# create or replace procedure p(a inout int default 7) as $$
>> >> begin return; end; $$ language plpgsql;
>> >> CREATE PROCEDURE
>> >> Time: 1.182 ms
>> >> postgres=# call p();
>> >
2018-03-20 15:18 GMT+01:00 Merlin Moncure :
> On Tue, Mar 20, 2018 at 9:09 AM, Pavel Stehule
> wrote:
> >> Edit: In one case, after dropping the function and recreating it, I
> >> got the procedure to return 0 where it had not before, so this smells
> >> like a bug.
> >> postgres=# call p();
> >>
On Tue, Mar 20, 2018 at 9:09 AM, Pavel Stehule wrote:
>> Edit: In one case, after dropping the function and recreating it, I
>> got the procedure to return 0 where it had not before, so this smells
>> like a bug.
>> postgres=# call p();
>> 2018-03-20 09:04:50.543 CDT [21494] ERROR: function p() d
2018-03-20 15:05 GMT+01:00 Merlin Moncure :
> On Wed, Feb 28, 2018 at 4:28 PM, Peter Eisentraut
> wrote:
> > This patch set adds support for INOUT parameters to procedures.
> > Currently, INOUT and OUT parameters are not supported.
> >
> > A top-level CALL returns the output parameters as a resul
On Wed, Feb 28, 2018 at 4:28 PM, Peter Eisentraut
wrote:
> This patch set adds support for INOUT parameters to procedures.
> Currently, INOUT and OUT parameters are not supported.
>
> A top-level CALL returns the output parameters as a result row. In
> PL/pgSQL, I have added special support to pa
On Tue, Mar 20, 2018 at 6:38 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 3/19/18 03:25, Rushabh Lathia wrote:
> > For the FUNCTION when we have single OUT/INOUT parameter
> > the return type for that function will be set to the type of OUT
> parameter.
> > But in case of P
On 3/19/18 03:25, Rushabh Lathia wrote:
> For the FUNCTION when we have single OUT/INOUT parameter
> the return type for that function will be set to the type of OUT parameter.
> But in case of PROCEDURE, it's always RECORDOID, why this inconsistency?
For procedures, this is just an implementatio
Thanks Peter for working on this. Sorry for the delay in raising this
questions.
1)
@@ -302,7 +304,9 @@ interpret_function_parameter_list(ParseState *pstate,
/* handle output parameters */
if (fp->mode != FUNC_PARAM_IN && fp->mode != FUNC_PARAM_VARIADIC)
{
- if
Jeff Janes writes:
> On Thu, Mar 15, 2018 at 6:58 AM, Tom Lane wrote:
>> Not fixed by 8df5a1c868cc28f89ac6221cff8e2b5c952d0eb6?
> I think you meant to type "now fixed by". (unless your compiler is pickier
> than mine)
Actually what I meant was "doesn't that commit fix it for you?"
On Thu, Mar 15, 2018 at 6:58 AM, Tom Lane wrote:
> Jeff Janes writes:
> > I'm getting compiler warnings:
> > pl_exec.c: In function 'exec_stmt_call':
> > pl_exec.c:2089:8: warning: variable 'numargs' set but not used
>
> Not fixed by 8df5a1c868cc28f89ac6221cff8e2b5c952d0eb6?
>
I think you meant
Jeff Janes writes:
> I'm getting compiler warnings:
> pl_exec.c: In function 'exec_stmt_call':
> pl_exec.c:2089:8: warning: variable 'numargs' set but not used
Not fixed by 8df5a1c868cc28f89ac6221cff8e2b5c952d0eb6?
regards, tom lane
On Wed, Mar 14, 2018 at 10:46 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> committed
>
>
I'm getting compiler warnings:
pl_exec.c: In function 'exec_stmt_call':
pl_exec.c:2089:8: warning: variable 'numargs' set but not used
[-Wunused-but-set-variable]
int numargs;
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
2018-03-13 14:14 GMT+01:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
> On 3/8/18 02:25, Pavel Stehule wrote:
> > It looks like some error in this concept. The rules for enabling
> > overwriting procedures should modified, so this collision should not be
> > done.
> >
> > When I using p
L Development, 24x7 Support, Remote DBA, Training & Services
From 5b9f1506e73826f4f6ff567e54b12c4e232a4263 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Mon, 12 Mar 2018 21:39:26 -0400
Subject: [PATCH v4] Support INOUT parameters in procedures
In a top-level CALL, the values of INOUT para
Hi
2018-03-08 1:53 GMT+01:00 Peter Eisentraut :
> On 3/6/18 04:22, Pavel Stehule wrote:
> > why just OUT variables are disallowed?
> >
> > The oracle initializes these values to NULL - we can do same?
>
> The problem is function call resolution. If we see a call like
>
> CALL foo(a, b, c);
>
> t
; Services
From 3c5ed2faab30dfcde34dfd58877e45a7f6477237 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Wed, 7 Mar 2018 19:15:35 -0500
Subject: [PATCH v3] Support INOUT parameters in procedures
In a top-level CALL, the values of INOUT parameters will be returned as
a result row. In PL/pgSQ
2018-03-05 19:38 GMT+01:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
> On 3/5/18 11:00, Pavel Stehule wrote:
> > I am looking on attached code, and it looks pretty well. Can be really
> > nice if this code will be part of release 11, because it is very
> > interesting, important featur
2018-03-05 19:41 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-05 19:38 GMT+01:00 Peter Eisentraut com>:
>
>> On 3/5/18 11:00, Pavel Stehule wrote:
>> > I am looking on attached code, and it looks pretty well. Can be really
>> > nice if this code will be part of release 11, because it is very
>> > inte
2018-03-05 19:38 GMT+01:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
> On 3/5/18 11:00, Pavel Stehule wrote:
> > I am looking on attached code, and it looks pretty well. Can be really
> > nice if this code will be part of release 11, because it is very
> > interesting, important featur
tainly a plausible extension for the future.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 8ce8ae9e59611e1a01f7507a6595f50416b761cc Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Mon, 5 Mar 2018 12:
>
> At the top-level, it's even more dubious. In DB2, apparently you write
>>
>> CALL foo(123, ?);
>>
>> with a literal ? for the OUT parameters.
>>
>
That's not actually as scary as it seems.
DB2 has two cases where you can use a ? like that:
1) In CLP (DB2's equivalent to psql)
DB2 draws a di
Hi
2018-02-28 23:28 GMT+01:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
> This patch set adds support for INOUT parameters to procedures.
> Currently, INOUT and OUT parameters are not supported.
>
> A top-level CALL returns the output parameters as a result row. In
> PL/pgSQL, I have
cid);
extern float4 get_func_rows(Oid funcid);
base-commit: bc1adc651b8e60680aea144d51ae8bc78ea6b2fb
prerequisite-patch-id: f46ead32b2ef64d66cc1994da7db6e57857c0270
prerequisite-patch-id: 62e1cab8d489dfd26af5b0f48f17a48cb63f
--
2.16.2
From 51725d637e343dde7438ea232f1cb1d16e8ad0a1 Mon Sep 17 00:
25 matches
Mail list logo
