Re: Name proliferation in functions with OUT parameters

Erwin Brandstetter wrote:
> Hi Dave!
>
> dpage@postgresql.org wrote:
>> http://svn.pgadmin.org/cgi-bin/viewcvs.cgi?rev=6259&view=rev
>> http://svn.pgadmin.org/cgi-bin/viewcvs.cgi?rev=6014&view=rev
>>
>> Thanks for the bug report though! I'll post a new snapshot soon and
>> mail the list so you can be using more up to date code.
>
> I've had a look at the code. Sure looks like a major rewrite even if one
> can't properly read C++. Promising! :)
> I think the reported issue is rather grave, as it can silently change
> functionality and break things. Therefore a new snapshot is very welcome.

Later tonight, if not, tomorrow - promise!!

> Btw: I am sure you are aware that OUT parameters or parameter names are
> not part of the function signature. This entry in the changelog suggests
> otherwise - or did I get it wrong?
> http://pgadmin.org/development/changelog.php
>
>> 2007-03-14 DP  1.8.0  Function/procedure signatures do not include OUT
>> params.
>>                       Fix this oversight, and cleanup much of the
>> related code.

You're reading it backwards. I was fixing the incorrect code that did
include the out params when in shouldn't have. It's correct now - it's
been extensively tested with PostgreSQL functions and EnterpriseDB
stored procedures. I'm sure you'll still find something I missed though :-p

> Currently pgAdmin 1.6.3 includes OUT parameters in many places where
> they aren't actually needed. Example:
>     ALTER FUNCTION myfunc(IN a integer, OUT b text) OWNER TO postgres;
> This would suffice:
>     ALTER FUNCTION myfunc(integer) OWNER TO postgres;
>
> Sorry if I am telling you things you already know. Just to make sure ..

Yeah - per the message, it was fixed for 1.8.0. It was too much of an
invasive fix for 1.6.x, and too close to 1.8 anyway.

>
> Speaking of function management - I have mentioned this before on list
> (as have others): one of my biggest wishes would be to merge the two
> nodes "Procedures" and "Functions". The separation does not fit in with
> Postgresql. It's causing me extra work and is a constant source of
> confusion. Is this changelog entry  the good news I think it is?
>
> 2007-03-09 DP  1.8.0  Treat all functions & procedures as 'Functions' in
>                      PostgreSQL, and class only EnterpriseDB edbspl
> functions
>                      returning void as 'Procedures'.

Yup. If it ain't an edbspl stored procedure returning void it's a
function. The Procedures collection node isn't even shown unless your
running EnterpriseDB.

Regards, Dave.