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 <[email protected]> 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 ([email protected]) > > 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 >
