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
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
Marko Kreen mark...@gmail.com 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
On Wed, Jan 25, 2012 at 10:23:14AM -0500, Tom Lane wrote:
Marko Kreen mark...@gmail.com 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
Marko Kreen mark...@gmail.com 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?
On Wed, Jan 25, 2012 at 11:40 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Kreen mark...@gmail.com 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
On Wed, Jan 25, 2012 at 11:40:28AM -0500, Tom Lane wrote:
Marko Kreen mark...@gmail.com 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
Marko Kreen mark...@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
On Wed, Jan 25, 2012 at 11:24 AM, Marko Kreen mark...@gmail.com 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
On Wed, Jan 25, 2012 at 12:58:15PM -0500, Tom Lane wrote:
Marko Kreen mark...@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
On Wed, Jan 25, 2012 at 12:54:00PM -0600, Merlin Moncure wrote:
On Wed, Jan 25, 2012 at 11:24 AM, Marko Kreen mark...@gmail.com 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
On Wed, Jan 25, 2012 at 1:24 PM, Marko Kreen mark...@gmail.com 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 mark...@gmail.com wrote:
I specifically want to avoid any sort of per-connection
negotation, except the max
On Wed, Jan 25, 2012 at 01:43:03PM -0600, Merlin Moncure wrote:
On Wed, Jan 25, 2012 at 1:24 PM, Marko Kreen mark...@gmail.com 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 mark...@gmail.com wrote:
I specifically want
On Wed, Jan 25, 2012 at 2:29 PM, Marko Kreen mark...@gmail.com 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
On Wed, Jan 25, 2012 at 02:50:09PM -0600, Merlin Moncure wrote:
On Wed, Jan 25, 2012 at 2:29 PM, Marko Kreen mark...@gmail.com wrote:
well, I see the following cases:
1) Vserver Vapplication: server downgrades wire formats to
applications version
2) Vapplication Vlibpq Vserver: since
On 01/25/2012 06:40 PM, Tom Lane wrote:
Marko Kreenmark...@gmail.com 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
On Mon, Jan 23, 2012 at 5:49 PM, Merlin Moncure mmonc...@gmail.com 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
On Tue, Jan 24, 2012 at 8:26 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jan 23, 2012 at 5:49 PM, Merlin Moncure mmonc...@gmail.com 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
On Tue, Jan 24, 2012 at 11:16 AM, Merlin Moncure mmonc...@gmail.com 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
On Tue, Jan 24, 2012 at 11:55 AM, Robert Haas robertmh...@gmail.com 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
Merlin Moncure mmonc...@gmail.com writes:
On Tue, Jan 24, 2012 at 11:55 AM, Robert Haas robertmh...@gmail.com 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,
On Tue, Jan 24, 2012 at 8:13 PM, Tom Lane t...@sss.pgh.pa.us 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,
On Sun, Jan 22, 2012 at 11:47 PM, Mikko Tiihonen
mikko.tiiho...@nitorcreations.com 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
On Mon, Jan 23, 2012 at 9:59 AM, Marko Kreen mark...@gmail.com wrote:
On Sun, Jan 22, 2012 at 11:47 PM, Mikko Tiihonen
mikko.tiiho...@nitorcreations.com wrote:
* introduced a new GUC variable array_output copying the current
bytea_output type, with values full (old value) and
smallfixed
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 23, 2012 at 9:59 AM, Marko Kreen mark...@gmail.com 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
On Mon, Jan 23, 2012 at 11:20:52AM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 23, 2012 at 9:59 AM, Marko Kreen mark...@gmail.com wrote:
Now that I think about it, same applies to bytea_output?
Probably so. But I think we need not introduce quite so many
Marko Kreen mark...@gmail.com 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
On Jan 23, 2012, at 2:49 PM, Tom Lane wrote:
Marko Kreen mark...@gmail.com 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
On Mon, Jan 23, 2012 at 2:00 PM, A.M. age...@themactionfaction.com 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
On Jan 23, 2012, at 4:45 PM, Merlin Moncure wrote:
On Mon, Jan 23, 2012 at 2:00 PM, A.M. age...@themactionfaction.com 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
On Mon, Jan 23, 2012 at 4:12 PM, A.M. age...@themactionfaction.com 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
31 matches
Mail list logo
