Re: request for enhancement of protocol

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

sometimes I need show only some text. Now I get stack info.
lighter elog ~ sending text, not. proc, stack info.

>
> > 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.
>

libpq is "black box" for me :-(. I need support in psql and plpgsql. And not
in
async mode, or I need wraper over async mode:

multih = execute_multi('call somestoredproc');
while not (rec = fetch_rs(multih))
{
...
}

> > 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().

when I can use variables (in plpgsql now, in sql in future - package
variables) I have to remember form of function. I can't to call a(@x1, @x2).
Why. Caller don't know if I mean variant one or variant two. And I have to
use nonstandard convension select into a(). Nonstandard in separation in and
out variables. I prefere some restriction here.

>
> > 4. ping
>
>You mean, a ping command without requiring a login?
>

yes
> > 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?
>
SELECT works well if I expect scalar value. But if I expect table I have to
use diff. form
SELECT * FROM ... I see two modes of calling a) select - typed result, b)
call - untyped result. For point a I have different requirements than for
point b. And I see difference between statement call (clauses where, from,
.....) and statement call. PostgreSQL don't support procedures now, only
functions.

> > 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?

if you have to solve creating cross table for normal interactive using in
console, you have two possibilities: 1. call stored procedure which generate
temp wiew and user will do select from view, or procedure can create cursor
and user will do select from cursor. But you can't do in one procedure now.

>
> > 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?
>

yes. This is reason why procedures can't to use in select statement

> > 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.
>

I spent some time for looking way for implementing this into plpgsql. I
didn't find it. It's part of SPI too.

Pavel

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/