On Wed, Mar 21, 2012 at 09:28:22PM -0400, Robert Haas wrote:
> On Wed, Mar 21, 2012 at 9:22 PM, Tom Lane wrote:
> >> It strikes me that it likely wouldn't be any
> >> worse than, oh, say, flipping the default value of
> >> standard_conforming_strings,
> >
> > Really? It's taking away functionalit
On Thu, Mar 22, 2012 at 6:58 AM, Robert Haas wrote:
> On Wed, Mar 21, 2012 at 9:22 PM, Tom Lane wrote:
> >> It strikes me that it likely wouldn't be any
> >> worse than, oh, say, flipping the default value of
> >> standard_conforming_strings,
> >
> > Really? It's taking away functionality and n
On Thu, Mar 22, 2012 at 9:31 AM, Simon Riggs wrote:
> Surely it just stops you using that idea 100% of the time. I don't see
> why you can't have this co-exist with the current mechanism. So it
> doesn't kill it for the common case.
I guess you could use it if you knew that there were no DELETE o
On Wed, Mar 21, 2012 at 8:28 PM, Robert Haas wrote:
> On Wed, Mar 21, 2012 at 9:22 PM, Tom Lane wrote:
>>> It strikes me that it likely wouldn't be any
>>> worse than, oh, say, flipping the default value of
>>> standard_conforming_strings,
>>
>> Really? It's taking away functionality and not sup
On Thu, Mar 22, 2012 at 1:28 AM, Robert Haas wrote:
> On Wed, Mar 21, 2012 at 9:22 PM, Tom Lane wrote:
>>> It strikes me that it likely wouldn't be any
>>> worse than, oh, say, flipping the default value of
>>> standard_conforming_strings,
>>
>> Really? It's taking away functionality and not sup
On Wed, Mar 21, 2012 at 9:22 PM, Tom Lane wrote:
>> It strikes me that it likely wouldn't be any
>> worse than, oh, say, flipping the default value of
>> standard_conforming_strings,
>
> Really? It's taking away functionality and not supplying any substitute
> (or at least you did not propose any
Robert Haas writes:
> On Wed, Mar 21, 2012 at 8:44 PM, Tom Lane wrote:
>> Oh, right. So scratch that objection. The other one is still fatal
>> though ...
> So, could we just decide that we don't care about preserving that
> property any more, and document it as an incompatibility in whatever
On Wed, Mar 21, 2012 at 8:44 PM, Tom Lane wrote:
> Oh, right. So scratch that objection. The other one is still fatal
> though ...
So, could we just decide that we don't care about preserving that
property any more, and document it as an incompatibility in whatever
release we break it in? It s
Robert Haas writes:
> On Wed, Mar 21, 2012 at 8:13 PM, Tom Lane wrote:
>> Another issue, quite independent from race conditions against other
>> observers of the row, is what if the tuple is part of an update chain?
>> You have no way to find the predecessor row version and update its
>> t_ctid f
On Wed, Mar 21, 2012 at 8:13 PM, Tom Lane wrote:
> I wrote:
>> Robert Haas writes:
>>> Specifically, I'm wondering if we couldn't get away with rearranging
>>> things so that the root line pointer (which has index entries) points
>>> to the actual tuple, and the other line pointer (which can't ha
I wrote:
> Robert Haas writes:
>> Specifically, I'm wondering if we couldn't get away with rearranging
>> things so that the root line pointer (which has index entries) points
>> to the actual tuple, and the other line pointer (which can't have any
>> index entries) gets marked UNUSED.
> This wou
Robert Haas writes:
> Specifically, I'm wondering if we couldn't get away with rearranging
> things so that the root line pointer (which has index entries) points
> to the actual tuple, and the other line pointer (which can't have any
> index entries) gets marked UNUSED.
This would amount to chan
12 matches
Mail list logo
