Re: Fwd: Need help in porting Oracle PL/SQL's OUT paramater based procedures - Mailing list pgsql-general

From Richard Huxton
Subject Re: Fwd: Need help in porting Oracle PL/SQL's OUT paramater based procedures
Date
Msg-id 49942529.5080303@archonet.com
Whole thread Raw
In response to Re: Fwd: Need help in porting Oracle PL/SQL's OUT paramater based procedures  (Gurjeet Singh <singh.gurjeet@gmail.com>)
List pgsql-general
Removed -hackers from the mailing-lists. Just noticed it, and I think
this is probably fine on the general list.

Gurjeet Singh wrote:
> On Thu, Feb 12, 2009 at 6:18 PM, Richard Huxton <dev@archonet.com> wrote:

>> CREATE OR REPLACE FUNCTION f1(IN a integer, INOUT b integer, OUT c
>> integer) RETURNS RECORD AS $$

> You see, you did not pass the third (OUT) parameter when calling the
> function:
>
>    r := f1(a, b);
>
> This differs from Oracle syntax where you _need_ to pass the third
> parameter.

That's because pl/pgsql isn't pl/sql. If you want to keep close, you can
just declare "c" as INOUT.

The original problem was that it was a pain to declare types for every
function that returned more than just a simple scalar. The alternative
was to say you returned RECORD, but then you needed to list column-names
when calling the function. Finally, IN/OUT/INOUT was abused to provide
an implicit record-type declaration for you. It's convenient for simple
cases, but it's not actually what I think of as IN/OUT parameters.

> And what if the Oracle function actually returns a value too? How do we
> handle that in the application, because we can't declare RECORD vars in
> Java/perl/python etc.

You can always do something like: SELECT b,c FROM f1(1, 2);


Realistically, I don't think you're going to get one set of queries
running against both RDBMS.

--
  Richard Huxton
  Archonet Ltd

pgsql-general by date:

Previous
From: Grzegorz Jaśkiewicz
Date:
Subject: Re: Update table with random values from another table
Next
From: Joshua Tolley
Date:
Subject: Re: Two-phase commmit, plpgsql and plproxy