Re: request for enhancement of protocol
От | Martijn van Oosterhout |
---|---|
Тема | Re: request for enhancement of protocol |
Дата | |
Msg-id | 20051119103551.GB8630@svana.org обсуждение исходный текст |
Ответ на | request for enhancement of protocol ("Pavel Stehule" <pavel.stehule@hotmail.com>) |
Ответы |
Re: request for enhancement of protocol
("Pavel Stehule" <pavel.stehule@hotmail.com>)
|
Список | 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.
В списке pgsql-hackers по дате отправления: