On 01/25/2012 06:40 PM, Tom Lane wrote:
Marko Kreen writes:
On Wed, Jan 25, 2012 at 10:23:14AM -0500, Tom Lane wrote:
Huh? How can that work? If we decide to change the representation of
some other "well known type", say numeric, how do we decide whether a
client setting that bit is expectin
On Wed, Jan 25, 2012 at 02:50:09PM -0600, Merlin Moncure wrote:
> On Wed, Jan 25, 2012 at 2:29 PM, Marko Kreen wrote:
> >> well, I see the following cases:
> >> 1) Vserver > Vapplication: server downgrades wire formats to
> >> applications version
> >> 2) Vapplication > Vlibpq > Vserver: since the
On Wed, Jan 25, 2012 at 2:29 PM, Marko Kreen wrote:
>> well, I see the following cases:
>> 1) Vserver > Vapplication: server downgrades wire formats to
>> applications version
>> 2) Vapplication > Vlibpq > Vserver: since the application is
>> reading/writing formats the server can't understand, an
On Wed, Jan 25, 2012 at 01:43:03PM -0600, Merlin Moncure wrote:
> On Wed, Jan 25, 2012 at 1:24 PM, Marko Kreen wrote:
> > On Wed, Jan 25, 2012 at 12:54:00PM -0600, Merlin Moncure wrote:
> >> On Wed, Jan 25, 2012 at 11:24 AM, Marko Kreen wrote:
> >> > I specifically want to avoid any sort of per-c
On Wed, Jan 25, 2012 at 1:24 PM, Marko Kreen wrote:
> On Wed, Jan 25, 2012 at 12:54:00PM -0600, Merlin Moncure wrote:
>> On Wed, Jan 25, 2012 at 11:24 AM, Marko Kreen wrote:
>> > I specifically want to avoid any sort of per-connection
>> > negotation, except the "max format version supported",
>>
On Wed, Jan 25, 2012 at 12:54:00PM -0600, Merlin Moncure wrote:
> On Wed, Jan 25, 2012 at 11:24 AM, Marko Kreen wrote:
> > 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 conn
On Wed, Jan 25, 2012 at 12:58:15PM -0500, Tom Lane wrote:
> Marko Kreen 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
> >> a
On Wed, Jan 25, 2012 at 11:24 AM, Marko Kreen wrote:
> 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,
Marko Kreen 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 negot
On Wed, Jan 25, 2012 at 11:40:28AM -0500, Tom Lane wrote:
> Marko Kreen writes:
> > On Wed, Jan 25, 2012 at 10:23:14AM -0500, Tom Lane wrote:
> >> Huh? How can that work? If we decide to change the representation of
> >> some other "well known type", say numeric, how do we decide whether a
> >>
On Wed, Jan 25, 2012 at 11:40 AM, Tom Lane wrote:
> Marko Kreen writes:
>> On Wed, Jan 25, 2012 at 10:23:14AM -0500, Tom Lane wrote:
>>> Huh? How can that work? If we decide to change the representation of
>>> some other "well known type", say numeric, how do we decide whether a
>>> client sett
Marko Kreen writes:
> On Wed, Jan 25, 2012 at 10:23:14AM -0500, Tom Lane wrote:
>> Huh? How can that work? If we decide to change the representation of
>> some other "well known type", say numeric, how do we decide whether a
>> client setting that bit is expecting that change or not?
> It sets
On Wed, Jan 25, 2012 at 10:23:14AM -0500, Tom Lane wrote:
> Marko Kreen writes:
> > On Tue, Jan 24, 2012 at 09:33:52PM -0500, Robert Haas wrote:
> >> Furthermore, while we haven't settled the question of exactly what a
> >> good negotiation facility would look like, we seem to agree that a GUC
> >
Marko Kreen writes:
> On Tue, Jan 24, 2012 at 09:33:52PM -0500, Robert Haas wrote:
>> Furthermore, while we haven't settled the question of exactly what a
>> good negotiation facility would look like, we seem to agree that a GUC
>> isn't it. I think that means this isn't going to happen for 9.2,
On Tue, Jan 24, 2012 at 09:33:52PM -0500, Robert Haas wrote:
> Furthermore, while we haven't settled the question of exactly what a
> good negotiation facility would look like, we seem to agree that a GUC
> isn't it. I think that means this isn't going to happen for 9.2, so
> we should mark this p
On tis, 2012-01-24 at 20:13 -0500, Tom Lane wrote:
> Yeah. In both cases, the (proposed) new output format is
> self-identifying *to clients that know what to look for*.
> Unfortunately it would only be the most anally-written pre-existing
> client code that would be likely to spit up on the unexp
On Tue, Jan 24, 2012 at 8:13 PM, Tom Lane wrote:
>> Well, the bytea experience was IMNSHO a complete disaster (It was
>> earlier mentioned that jdbc clients were silently corrupting bytea
>> datums) and should be held up as an example of how *not* to do things;
>
> Yeah. In both cases, the (propo
Merlin Moncure writes:
> On Tue, Jan 24, 2012 at 11:55 AM, Robert Haas wrote:
>> I do wonder whether we are making a mountain out of a mole-hill here,
>> though. If I properly understand the proposal on the table, which
>> it's possible that I don't, but if I do, the new format is
>> self-identi
On Tue, Jan 24, 2012 at 11:55 AM, Robert Haas wrote:
> I do wonder whether we are making a mountain out of a mole-hill here,
> though. If I properly understand the proposal on the table, which
> it's possible that I don't, but if I do, the new format is
> self-identifying: when the optimization i
On Tue, Jan 24, 2012 at 11:16 AM, Merlin Moncure wrote:
>> Our current protocol allocates a 2-byte integer for the purposes of
>> specifying the type of each parameter, and another 2-byte integer for
>> the purpose of specifying the result type... but only one bit is
>> really needed at present: t
On Tue, Jan 24, 2012 at 8:26 AM, Robert Haas wrote:
> On Mon, Jan 23, 2012 at 5:49 PM, Merlin Moncure wrote:
>> I'm not sure that you're getting anything with that user facing
>> complexity. The only realistic case I can see for explicit control of
>> wire formats chosen is to defend your applic
On Mon, Jan 23, 2012 at 5:49 PM, Merlin Moncure wrote:
> I'm not sure that you're getting anything with that user facing
> complexity. The only realistic case I can see for explicit control of
> wire formats chosen is to defend your application from format changes
> in the server when upgrading t
On Mon, Jan 23, 2012 at 4:12 PM, A.M. wrote:
> On Jan 23, 2012, at 4:45 PM, Merlin Moncure wrote:
>> Prefer the version. But why send this over and over with each bind?
>> Wouldn't you negotiate that when connecting? Most likely, optionally,
>> doing as much as you can from the server version? P
On Jan 23, 2012, at 4:45 PM, Merlin Moncure wrote:
> On Mon, Jan 23, 2012 at 2:00 PM, A.M. wrote:
>> One simple way clients could detect the binary encoding at startup would be
>> to pass known test parameters and match against the returned values. If the
>> client cannot match the response, t
On Mon, Jan 23, 2012 at 2:00 PM, A.M. wrote:
> One simple way clients could detect the binary encoding at startup would be
> to pass known test parameters and match against the returned values. If the
> client cannot match the response, then it should choose the text
> representation.
>
> Alter
On Jan 23, 2012, at 2:49 PM, Tom Lane wrote:
> Marko Kreen writes:
>> [ bytea_output doesn't need to be GUC_REPORT because format is
>> autodetectable ]
>
> Fair enough. Anyway we're really about two years too late to revisit that.
>
>> Btw, it does not seems that per-request metainfo change
Marko Kreen writes:
> [ bytea_output doesn't need to be GUC_REPORT because format is autodetectable
> ]
Fair enough. Anyway we're really about two years too late to revisit that.
> Btw, it does not seems that per-request metainfo change requires
> "major version". It just client can send extr
On Mon, Jan 23, 2012 at 11:20:52AM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jan 23, 2012 at 9:59 AM, Marko Kreen wrote:
> >> Now that I think about it, same applies to bytea_output?
>
> > Probably so. But I think we need not introduce quite so many new
> > threads on this patch.
Robert Haas writes:
> On Mon, Jan 23, 2012 at 9:59 AM, Marko Kreen wrote:
>> Now that I think about it, same applies to bytea_output?
> Probably so. But I think we need not introduce quite so many new
> threads on this patch. This is, I think, at least thread #4, and
> that's making the discus
On Mon, Jan 23, 2012 at 9:59 AM, Marko Kreen wrote:
> On Sun, Jan 22, 2012 at 11:47 PM, Mikko Tiihonen
> wrote:
>> * introduced a new GUC variable array_output copying the current
>> bytea_output type, with values "full" (old value) and
>> "smallfixed" (new default)
>> * added documentation for
On Sun, Jan 22, 2012 at 11:47 PM, Mikko Tiihonen
wrote:
> * introduced a new GUC variable array_output copying the current
> bytea_output type, with values "full" (old value) and
> "smallfixed" (new default)
> * added documentation for the new GUC variable
If this variable changes protocol-leve
On Sun, Jan 22, 2012 at 11:47:06PM +0200, Mikko Tiihonen wrote:
> On 01/20/2012 04:45 AM, Noah Misch wrote:
>> On Thu, Jan 19, 2012 at 02:00:20PM -0500, Robert Haas wrote:
>>> Having said that, if we're to follow the precedent set by
>>> bytea_format, maybe we ought to just add
>>> binary_array_for
Previous title was: Add minor version to v3 protocol to allow changes without
breaking backwards compatibility
On 01/20/2012 04:45 AM, Noah Misch wrote:
On Thu, Jan 19, 2012 at 02:00:20PM -0500, Robert Haas wrote:
On Thu, Jan 19, 2012 at 10:37 AM, Noah Misch wrote:
I agree with Merlin; the
33 matches
Mail list logo
