Re: protocol change in 7.4

Questions have arisen during discussions about errors relating
to how to support error codes without changing the FE/BE
protocols. (see TODO.detail/error)

Now that the protocol is up for revision, how about supporting
sql state strings, error codes, and other information directly in
the protocol.

Regards,
Grant

Neil Conway wrote:

> There has been some previous discussion of changing the FE/BE protocol
> in 7.4, in order to fix several problems. I think this is worth doing:
> if we can resolve all these issues in a single release, it will lessen
> the upgrade difficulties for users.
>
> I'm aware of the following problems that need a protocol change to fix
> them:
>
>         (1) Add an optional textual message to NOTIFY
>
>         (2) Remove the hard-coded limits on database and user names
>             (SM_USER, SM_DATABASE), replace them with variable-length
>             fields.
>
>         (3) Remove some legacy elements in the startup packet
>             ('unused' can go -- perhaps 'tty' as well). I think the
>             'length' field of the password packet is also not used,
>             but I'll need to double-check that.
>
>         (4) Fix the COPY protocol (Tom?)
>
>         (5) Fix the Fastpath protocol (Tom?)
>
>         (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).
>
>         (7) Include the current transaction status, since it's
>             difficult for the client app to determine it for certain
>             (Tom/Bruce?)
>
> If I've missed anything or if there is something you think we should
> add, please let me know.
>
> I can implement (1), (2), (3), and possibly (7), if someone can tell
> me exactly what is required (my memory of the discussion relating to
> this is fuzzy). The rest is up for grabs.
>
> Finally, how should we manage the transition? I wasn't around for the
> earlier protocol changes, so I'd appreciate any input on steps we can
> take to improve backward-compatibility.
>
> Cheers,
>
> Neil
>