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

Hi,

> Are there any catalog changes with the refactoring, that change the
> way parameters are represented that need to be reflected elsewhere in
> pgFunction.cpp?
>
>
Ummm, nothing that comes to mind immediately. I think pronargs does not
contain OUT params for SPL objects anymore. But did not see any ill-effects
of this in my limited testing.

Additionally, this patch already handles the "_retval_" parameter
appropriately. So as of now dare I say things look ok, but we might do some
more coding to handle any reported issues later. Won't be earth-shattering
fixes though IMO...

> 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.
>
> +1 from the patch-submitter (if it counts ;))

Regards,
Nikhils

> 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
>