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

From Hans-Jürgen Schönig
Subject Re: request for enhancement of protocol
Date
Msg-id 437F00CA.3070403@cybertec.at
Whole thread Raw
In response to request for enhancement of protocol  ("Pavel Stehule" <pavel.stehule@hotmail.com>)
List pgsql-hackers
i think if the protocol is enhanced again we should also consider adding 
protocol level support for RESET CONNECTION.
i have sent this patch some time ago but i think it is not worth to do 
the remaining protocol level changes (sql level support is finished) if 
this is the only change on the protocol level.
    best regards,
        hans


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)
> 2. multi result sets. This is necessery for support procedures in DB2, 
> MySQL, "ANSI", MsSQL style.
> 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.
> 4. ping
> 
> 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, ...
>  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. This is difference between procedures 
> and functions. Function have to have exactly defined interface. 
> Procedures can't.
>  3. easy porting from databases which support this style.
> 
> sorry for my wrong english.
> 
> best regards
> Pavel Stehule
> 
> _________________________________________________________________
> Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. 
> http://www.msn.cz/
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>       choose an index scan if your joining column's datatypes do not
>       match


-- 
Cybertec Geschwinde & Schönig GmbH
Schöngrabern 134; A-2020 Hollabrunn
Tel: +43/1/205 10 35 / 340
www.postgresql.at, www.cybertec.at


pgsql-hackers by date:

Previous
From: Nicolas Barbier
Date:
Subject: Re: Materialized views (Was Re: Improving count(*))
Next
From: Martijn van Oosterhout
Date:
Subject: Returning multiple result sets