Tom,
I concur with the other comment that plpgql is intended to mimic
Oracle PL/SQL, not SQL/PSM. If we try to follow two different leads
we are likely to find ourselves with a mess.
Well, the proposed functionality would be extremely useful in making
PL/pgSQL a more robust language. So ca
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Pavel Stehule wrote:
>> I looked into SQL2003, and SQL2003 knows it (SQL/PSM):
>>
>> ::=
>>
>> |
>> ::=
>> SET
>> ::=
>> [ {
>> }... ]
>> ::=
>> SET
> The parentheses are apparently required for multiple variables, so in
> our case i
On 8/8/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Are we intending to support SQL/PSM with PL/pgSQL?
I hope not. While PL/pgSQL and SQL/PSM share some similarities, they
should be totally separate. IIRC, EnterpriseDB had tried to sponsor
someone to write SQL/PSM support for PostgreSQL a li
Andrew Dunstan wrote:
> Pavel Stehule wrote:
> >I looked into SQL2003, and SQL2003 knows it (SQL/PSM):
> > [grammar productions]
>
> The parentheses are apparently required for multiple variables, so in
> our case it might look like this:
>
> (a,b,c) := foo(bar);
>
> That might overcome the ob
Pavel Stehule wrote:
Tom Lane wrote:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> a,b,c := out3fce(1); -- Simultaneous assignment
>
> I thought we rejected that idea once already, on the grounds that it
> would make it too hard to tell the difference between intended code
> and typos.
>
In
Tom Lane wrote:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> a,b,c := out3fce(1); -- Simultaneous assignment
>
> I thought we rejected that idea once already, on the grounds that it
> would make it too hard to tell the difference between intended code
> and typos.
>
In any case, I had some
Martijn van Oosterhout writes:
> Well, you can implement it. After all, the CALL syntax is merely
> syntactic sugar. You could (if you wanted to) do the following:
> CREATE FUNCTION foo( a TEXT IN, b TEXT INOUT, c TEXT OUT ) as blah...
> And in a pl/pgsql function, translate: "CALL foo(a,b,c)"
Martijn van Oosterhout writes:
> Well, you can implement it. After all, the CALL syntax is merely
> syntactic sugar. You could (if you wanted to) do the following:
> CREATE FUNCTION foo( a TEXT IN, b TEXT INOUT, c TEXT OUT ) as blah...
> And in a pl/pgsql function, translate: "CALL foo(a,b,c)"
On Mon, Aug 07, 2006 at 04:11:48PM +0200, Pavel Stehule wrote:
> The best of is implementation of CALL statement, where I can transmit
> values "by" references. But it's not possible in Postgres :-(. I can't to
> select unambiguously called procedure. "I can, if I accept SQL Server
> syntax, whe
Tom Lane wrote:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> a,b,c := out3fce(1); -- Simultaneous assignment
>
> I thought we rejected that idea once already, on the grounds that it
> would make it too hard to tell the difference between intended code
> and typos.
>
In any case, I had some q
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> a,b,c := out3fce(1); -- Simultaneous assignment
I thought we rejected that idea once already, on the grounds that it
would make it too hard to tell the difference between intended code
and typos.
Yes, because wasn't procedures with out params, my
Tom Lane wrote:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> a,b,c := out3fce(1); -- Simultaneous assignment
>
> I thought we rejected that idea once already, on the grounds that it
> would make it too hard to tell the difference between intended code
> and typos.
>
In any case, I had some que
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> a,b,c := out3fce(1); -- Simultaneous assignment
I thought we rejected that idea once already, on the grounds that it
would make it too hard to tell the difference between intended code
and typos.
regards, tom lane
13 matches
Mail list logo
