Re: pgAdmin III: adjust code as per new EDB AS90 functions/procedures semantics

Thanks Nikhil.

Are there any catalog changes with the refactoring, that change the
way parameters are represented that need to be reflected elsewhere in
pgFunction.cpp?

Also, does anyone object to back-patching this? It's not a bug fix,
but it does mean that we don't support corresponding versions of PPAS
and PG in the same version of pgAdmin which seems undesirable. The
patch is pretty straightforward and seems low risk.

On Mon, Feb 21, 2011 at 9:17 AM, Nikhil S <nixmisc(at)gmail(dot)com> wrote:
> Hi,
>
> In EDBAS 9.0, following notable restructuring has been done with respect to
> functions and procedures. We need to adopt the same in the pgAdmin code
> base. Note that these changes make EDBAS funcs/procs behave more like native
> Postgres functions which is a good thing:
>
> * To debug edb-SPL functions/procedures, the debugger was using custom
> EDB-protocol extension. With the latest refactorings, the normal code path
> which was being employed for plpgsql objects can be used. This patch checks
> for the version number at appropriate locations to avoid calling this custom
> protocol now. Obviously the current behavior has to be retained for pre 9.0
> versions. (changes in debugger files. Had to also make some misc. changes to
> handle default parameters appropriately.)
>
> *  Procedures with or without OUT-parameters can now also be called without
> the EDB-protocol extension with the EXEC command. For example, if you have a
> procedure like "fooproc(a IN integer, b OUT integer)", you can call it with
> "exec fooproc(123)". The OUT value is returned as the return value, just as
> if it was a function call. Again this behaviour will now be the same as for
> normal plpgsql objects.(pgFunction.cpp)
>
> * If an SPL-function has both an OUT-parameter and a return value, the
> return value is transformed into an extra OUT-parameter named "_retval_".
> This patch adds code to identify such a column and use its type to set the
> return type appropriately. (pgFunction.cpp)
>
> Note that the changes are not as intensive as the above may sound. The
> protocol extension was only being used by the debugger code paths, so the
> changes are localised in that module. The remaining changes are in
> pgFunction.cpp file only. I tested the debugger changes against both AS90
> and AS84 code bases. For the latter the extended protocol is getting invoked
> appropriately. No testing on windows though yet.
>
> Regards,
> Nikhils
>
>
> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>
>

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company