Re: request for enhancement of protocol - Mailing list pgsql-hackers

On Sat, Nov 19, 2005 at 11:07:58AM +0100, Pavel Stehule wrote:
> Hello
>
> Meybe is time for some changes. Maybe. I haven't courage for it. But maybe
> is good time for discussion.  What I miss in protocol?
>
> 1. debug. support + other level for elog. Current elog is too heavy
> (sometimes)

What do you mean? There are already 10 levels for elog, including five
levels of DEBUG. How many more do you want?

> 2. multi result sets. This is necessery for support procedures in DB2,
> MySQL, "ANSI", MsSQL style.

The protocol already supports this and libpq does also. However, I
think that unless you are using async mode you may have difficulty
retrieving it. There's also a comment there about whether the backend
can actually do it, so maybe some work need to be done there.

> 3. session (package) variables and calling procedures with OUT, INOUT in
> normal style, tj. stmt CALL. - heavy task, because I can write function
> a(IN int, IN int), and a(OUT int, OUT int) now. This is problem, and need
> restriction.

I can understand the CALL but what's the confusing between the two
functions a? One is a(1,2), the other is a().

> 4. ping

You mean, a ping command without requiring a login?

> What is my motivation for 2?
>  1. I can write "solution" - stored application. Example: info about
> growing of database. Output is n tables: first table is info about
> database, others about top n - 1 tables, ...

So you mean a function that can return anything (and hence cannot be
used in normal queries). And thus define a special interface for it
(CALL). Still, SELECT function() would work just as well, no?

>  2. easy reporting. I haven't possibility write stored procedure for
> generating cross table now. I have to do all in two steps (example):
> generate view, select from view.
Why do you need a view, why can't you use a subquery?

> This is difference between procedures and functions. Function have to
> have exactly defined interface. Procedures can't.

So essentially, "procedures" here are functions that return "unknown"
rather than functions that return nothing?

>  3. easy porting from databases which support this style.

Ok, valid point.

Interesting points all, but they seem to be more backend related than
protocol related.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.