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.
