Re: protocol change in 7.4

From: Christof Petig <christof(at)petig-baender(dot)de>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: protocol change in 7.4
Date: 2002-11-06 07:08:45
Message-ID: 3DC8BFFD.5040000@petig-baender.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Christof Petig wrote:
> Neil Conway wrote:
>
>> (6) Protocol-level support for prepared queries, in order to
>> bypass the parser (and maybe be more compatible with the
>> implementation of prepared queries in other databases).
>
>
> Let me add
> (6b) Protocol level support for query parameters. This would actually
> make (6) more powerful and speed up non prepared (but similar)
> queries via the query cache (which is already there IIRC).
> [I talk about <statement> USING :var ... ]
>
> (n) Platform independant binary representation of parameters and
> results (like in CORBA). This can _really_ speed up
> communication with compiled programs if you take the time to
> implement it. This was previously planned for a future
> CORBA fe/be protocol, but this does not seem to come any time
> soon.

After one night's sleep I think that perhaps a CORBA based protocol
might be less work (but I have no idea about a decent authentification
schema, I'd tend to reuse the already authentificated stream). A
corbaized query-only interface might easily cover these issues and be
less work than a full corba backend access. JDBC (I don't know much
about it) might give a reasonable interface design (perhaps combined
with a libpq[++|xx] like interface if there's benefit to it).

> (n+1) Optional additional Result qualifiers. E.g. dynamic embedded
> sql has a
> flag to indicate that this column is a key. Previously it was
> impossible to set this flag to a meaningful value. Also
> the standard has additional statistical information about the
> size of the column etc. If it's unclear what I'm talking about
> I will look up the exact location in the standard (it's embedded
> sql, dynamic sql, get descriptor)

This does not need an implementation soon. But the new protocol should
allow future things like this.

All these proposals are motivated by (future) ecpg [C/C++] needs. So
IMHO the ODBC, JDBC, libpqxx people might be interested in many of these
issues, too. We definitely should make sure to have asked them.

Yours
Christof

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Satoshi Nagayasu 2002-11-06 08:02:14 Re: protocol change in 7.4
Previous Message Matthew T. O'Connor 2002-11-06 06:53:08 Re: Win32 port