Tom Lane wrote: > * Backend should pass its version number, database encoding, default > client encoding, and possibly other data (any ideas?) to frontend during > startup, to avoid need for explicit queries to get this info. We could > also consider eliminating SET commands sent by libpq in favor of adding > variable settings to startup packet's PGOPTIONS field. Ideally we could > get back to the point where a standard connection startup takes only one > packet in each direction.
Should we pass this in a way where we can add stuff later, like passing it as a simple NULL-terminated string that can get split up on the client end. > One of the $64 questions that has to be answered is how much work we're > willing to expend on backwards compatibility. The path of least > resistance would be to handle it the same way we've done protocol > revisions in the past: the backend will be able to handle both old and new > protocols (so it can talk to old clients) but libpq would be revised to > speak only the new protocol (so new/recompiled clients couldn't talk to > old backends). We've gotten away with this approach in the past, but the > last time was release 6.4. I fully expect to hear more complaints now. I think such compatibility is sufficient. We can mention in the releases notes that they should upgrade there servers before their clients. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
