On Wed, Jan 25, 2012 at 12:58:15PM -0500, Tom Lane wrote:
> Marko Kreen <markokr@gmail.com> writes:
> > On Wed, Jan 25, 2012 at 11:40:28AM -0500, Tom Lane wrote:
> >> Then why bother with the bit in the format code? If you've already done
> >> some other negotiation to establish what datatype formats you will
> >> accept, this doesn't seem to be adding any value.
>
> > The "other negotiation" is done via Postgres release notes...
>
> That is really not going to work if the requirement is to not break old
> apps. They haven't read the release notes.
Yes, but they also keep requesting the old formats so everything is fine?
Note that formats are under full control of client, server has no way
to send newer formats to client that has not requested it.
> > I specifically want to avoid any sort of per-connection
> > negotation, except the "max format version supported",
> > because it will mess up multiplexed usage of single connection.
> > Then they need to either disabled advanced formats completely,
> > or still do it per-query somehow (via GUCs?) which is mess.
>
> Hmm, that adds yet another level of not-obvious-how-to-meet requirement.
> I tend to concur with Robert that we are not close to a solution.
Well, my simple scheme seems to work fine with such requirement.
[My scheme - client-supplied 16bit type code is only thing
that decides format.]
> > No, the list of "well-known" types is documented and fixed.
> > The bit is specifically for frameworks, so that they can say
> > "I support all well-known types in Postgres version X.Y".
>
> So in other words, if we have a client that contains a framework that
> knows about version N, and we connect it up to a server that speaks
> version N+1, it suddenly loses the ability to use any version-N
> optimizations? That does not meet my idea of not breaking old apps.
That is up to Postgres maintainers to decide, whether they want
to phase out some type from the list. But my main point was
it's OK to add types into list. I missed that aspect on my
previous mail.
--
marko
