Tom Lane writes:
> Topic branches defined that way seem like a pretty bad idea from here.
> They would save no effort at all for committers, because if you're not
> allowed to object to something after it's gone into a topic branch, then
> it's just like master in terms of having to keep up with c
Robert Haas writes:
> On Sun, Dec 5, 2010 at 12:41 PM, Andrew Dunstan wrote:
>> Well, ISTM that amounts to not having "official topic branches" :-) I agree
>> that this is supposed to be one of git's strengths (or more exactly a
>> strength of distributed SCM's generally). I don't really see any
Excerpts from Andrew Dunstan's message of dom dic 05 14:41:20 -0300 2010:
> What I would like to see is people publishing the location of
> development repos so that they can be pulled from or merged, especially
> for any large patch.
Yes, this is pretty useful. Dimitri published his repos for
On Sun, Dec 5, 2010 at 12:41 PM, Andrew Dunstan wrote:
> Well, ISTM that amounts to not having "official topic branches" :-) I agree
> that this is supposed to be one of git's strengths (or more exactly a
> strength of distributed SCM's generally). I don't really see any great
> value in sanctify
On 12/05/2010 12:10 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 12/04/2010 07:12 PM, Robert Haas wrote:
I wouldn't necessarily be opposed to official topic branches at some point in
the future, but I think it's premature to speculate about whether it'd be
useful here.
I'd need a lot of
Andrew Dunstan writes:
> On 12/04/2010 07:12 PM, Robert Haas wrote:
>> I wouldn't necessarily be opposed to official topic branches at some point
>> in the future, but I think it's premature to speculate about whether it'd be
>> useful here.
> I'd need a lot of convincing if it imposed an extr
On 12/04/2010 07:12 PM, Robert Haas wrote:
I wouldn't necessarily be opposed to official topic branches at some point in
the future, but I think it's premature to speculate about whether it'd be
useful here.
I'd need a lot of convincing if it imposed an extra burden on people
like Tom. T
On Dec 4, 2010, at 1:22 PM, Dimitri Fontaine
> That's calling for a try :)
>
> What about a new index type that follows the partitioning scheme in its
> root pages in a way that allow the locking to occur in a subpart of it,
> rather than for the whole index.
>
> Well, maybe that needs to have
On Sat, Dec 04, 2010 at 12:19:59PM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > Those are difficulties, certainly. Are they insurmountable
> > obstacles, though? This is something that has been on the TODO
> > list for ages and I think is very worth doing, if we can.
>
> They're possibly s
Andrew Dunstan writes:
> Anyone can create a branch and publish it. That's the democracy that git
> allows. So if you want it, don't argue for it, just do it.
The showstopper is having a unified plan for what to put in there, for
once, and having -core people (commiters) willing to either put gia
On 2010-12-04 19:22, Dimitri Fontaine wrote:
That's calling for a try :)
What about a new index type that follows the partitioning scheme in its
root pages in a way that allow the locking to occur in a subpart of it,
rather than for the whole index.
Would that (global) index be totally ordered?
On 12/04/2010 01:22 PM, Dimitri Fontaine wrote:
Given such an agenda, I'd argue for a feature branch being open for
partitioning so that incremental reviewed work can happen there until we
have enough pieces to consider merging into HEAD.
Anyone can create a branch and publish it. That's t
Tom Lane writes:
> partitioning. I have a feeling that the feature will languish on the
> TODO list forever, unless someone comes up with a brilliant idea to
> avoid the problems. As is, the return on investment to do it just
> isn't there.
That's calling for a try :)
What about a new index ty
Andrew Dunstan writes:
> Those are difficulties, certainly. Are they insurmountable obstacles,
> though? This is something that has been on the TODO list for ages and I
> think is very worth doing, if we can.
They're possibly surmountable with enough effort, though I think in
reality what you'd
On 12/04/2010 11:56 AM, Tom Lane wrote:
Greg Stark writes:
[ suggestion for cross-table indexes ]
That's been proposed before, and shot down before, though I don't recall
all the reasons offhand. One obvious problem is VACUUM, which assumes
that you can't have two processes trying to vacuu
Greg Stark writes:
> On Wed, Dec 1, 2010 at 3:05 PM, Tom Lane wrote:
>> Perhaps I should have said "possibly workable proposal". What you wrote
>> doesn't even begin to cover the interesting part of the problem, namely
>> how to ensure uniqueness is preserved in the face of concurrent
>> inserti
On Wed, Dec 1, 2010 at 3:05 PM, Tom Lane wrote:
> Perhaps I should have said "possibly workable proposal". What you wrote
> doesn't even begin to cover the interesting part of the problem, namely
> how to ensure uniqueness is preserved in the face of concurrent
> insertions.
I think it wouldn't
On 2010-12-02 01:18, Jim Nasby wrote:
On Dec 1, 2010, at 8:07 AM, Yeb Havinga wrote:
FK's cannot refer to rows in inheritance childs.
We have partially solved this issue at work. In our scenario, we're not using inheritance for
partitioning, we're using it for, well, inheriting. As part of tha
On 2010-12-01 16:58, Florian Pflug wrote:
On Dec1, 2010, at 15:27 , Tom Lane wrote:
Indeed. This isn't even worth the time to review, unless you have a
proposal for fixing the unique-index-across-multiple-tables problem.
I've wondered in the past if a unique index is really necessary on the c
On 2010-12-02 11:27, Yeb Havinga wrote:
With 'inheritance chain' I mean any set of more than one relation that
is the transitive closure of the inheritance parent and child relation
on a given relation.
s/transitive closure/transitive reflexive closure
--
Sent via pgsql-hackers mailing list
On 2010-12-01 16:05, Tom Lane wrote:
Perhaps I should have said "possibly workable proposal". What you wrote
doesn't even begin to cover the interesting part of the problem, namely
how to ensure uniqueness is preserved in the face of concurrent
insertions.
The usual page locking done by nbtree
On Dec 1, 2010, at 8:07 AM, Yeb Havinga wrote:
> FK's cannot refer to rows in inheritance childs.
We have partially solved this issue at work. In our scenario, we're not using
inheritance for partitioning, we're using it for, well, inheriting. As part of
that, we have a field in the parent table
On Dec1, 2010, at 17:11 , Kevin Grittner wrote:
> Florian Pflug wrote:
>
>> BTW, my "serializable_lock_consisteny" patch would allow you to do
>> this purely within pl/pgsql in a race-condition free way. So if
>> that patch should get applied you might want to consider this as a
>> workaround. Wh
On Wed, 2010-12-01 at 15:07 +0100, Yeb Havinga wrote:
> FK's cannot refer to rows in inheritance childs. With some changes in
> LockRows, together with removing the ONLY keyword in ri_trigger.c, it
> was possible to refer to the rows in child relations. (WIP patch attached)
This has a userspace
Florian Pflug wrote:
> BTW, my "serializable_lock_consisteny" patch would allow you to do
> this purely within pl/pgsql in a race-condition free way. So if
> that patch should get applied you might want to consider this as a
> workaround. Whether it will get applied is yet to be seen, though
> -
On Dec1, 2010, at 15:27 , Tom Lane wrote:
> Yeb Havinga writes:
>> FK's cannot refer to rows in inheritance childs. With some changes in
>> LockRows, together with removing the ONLY keyword in ri_trigger.c, it
>> was possible to refer to the rows in child relations. (WIP patch attached)
>
>> Th
Yeb Havinga writes:
> On 2010-12-01 15:27, Tom Lane wrote:
>> Indeed. This isn't even worth the time to review, unless you have a
>> proposal for fixing the unique-index-across-multiple-tables problem.
> That was in the part that you chose to not quote.
Perhaps I should have said "possibly work
On 2010-12-01 15:27, Tom Lane wrote:
Yeb Havinga writes:
FK's cannot refer to rows in inheritance childs. With some changes in
LockRows, together with removing the ONLY keyword in ri_trigger.c, it
was possible to refer to the rows in child relations. (WIP patch attached)
Though it passes simple
Yeb Havinga writes:
> FK's cannot refer to rows in inheritance childs. With some changes in
> LockRows, together with removing the ONLY keyword in ri_trigger.c, it
> was possible to refer to the rows in child relations. (WIP patch attached)
> Though it passes simple tests, it is far from comple
Hello list,
FK's cannot refer to rows in inheritance childs. With some changes in
LockRows, together with removing the ONLY keyword in ri_trigger.c, it
was possible to refer to the rows in child relations. (WIP patch attached)
Though it passes simple tests, it is far from complete. To our kno
30 matches
Mail list logo
