On Fri, Oct 21, 2011 at 5:08 AM, Kohei KaiGai wrote:
> It seems to me v9.0 implementation is correct. It might be enbugged
> when OpFamilyCacheLookup() get missing_ok argument. :-(
Yep, looks that way. Will fix.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
2011/10/20 Robert Haas :
> On Thu, Oct 20, 2011 at 10:49 AM, Kohei KaiGai wrote:
part-3: drop statement reworks for other object classes
>>>
>>> This is going to need some rebasing.
>>>
>> OK, I rebased it.
>>
>> This patch includes bug-fix when we tried to drop non-existence
>> operator fami
On Thu, Oct 20, 2011 at 10:49 AM, Kohei KaiGai wrote:
>>> part-3: drop statement reworks for other object classes
>>
>> This is going to need some rebasing.
>>
> OK, I rebased it.
>
> This patch includes bug-fix when we tried to drop non-existence
> operator family with IF EXISTS.
I'm thinking we
On Wed, Oct 19, 2011 at 11:33 PM, Robert Haas wrote:
> Committed. Which I just noticed broke the build farm. Will go fix that
> now...
Wow, that was a lot of pretty colors. Or not so pretty colors.
Seems to be turning green again now, so I'm going to bed. Will check
it again in the morning.
On Wed, Oct 19, 2011 at 3:30 PM, Kohei KaiGai wrote:
> part-1: only regression test of DROP [IF EXISTS] on unmodified master
Committed. Which I just noticed broke the build farm. Will go fix that now...
> part-2: drop statement reworks that uses T_DropStmt
Committed with some changes.
> part
On Thu, Oct 13, 2011 at 12:46 PM, Kohei KaiGai wrote:
> And, also I added regression test cases to detect these code paths,
> because some of object types does not cover the case when it was
> dropped.
These regression tests seem busted to me. First, I applied the part 2
patch. The regression t
2011/10/12 Robert Haas :
> On Wed, Oct 12, 2011 at 8:07 AM, Kohei KaiGai wrote:
>> I'm currently trying to revise my patches according to your suggestions,
>> but I'm facing a trouble about error messages when user tries to drop
>> a non-exists object.
>>
>> Because the ObjectProperty array has an
On Wed, Oct 12, 2011 at 8:07 AM, Kohei KaiGai wrote:
> I'm currently trying to revise my patches according to your suggestions,
> but I'm facing a trouble about error messages when user tries to drop
> a non-exists object.
>
> Because the ObjectProperty array has an entry for each catalogs, it is
Robert,
I'm currently trying to revise my patches according to your suggestions,
but I'm facing a trouble about error messages when user tries to drop
a non-exists object.
Because the ObjectProperty array has an entry for each catalogs, it is
unavailable to hold the name of object type (such as "
On Mon, Oct 10, 2011 at 1:38 PM, Kohei KaiGai wrote:
> I'm sorry again. I tought it was obvious from the filenames.
I guess I got confused because you re-posted part 2 without the other
parts, and I got mixed up and thought you were reposting part one.
I've committed a stripped-down version of t
> OK, well, I applied pgsql-v9.2-drop-reworks-2.v4.1.patch and tried to
> compile, and got this:
>
> In file included from ../../../src/include/catalog/dependency.h:17,
> from dependency.c:19:
> ../../../src/include/catalog/objectaddress.h:21: warning: type
> defaults to ‘int’ in de
On Mon, Oct 10, 2011 at 9:39 AM, Kohei KaiGai wrote:
> 2011/10/10 Robert Haas :
>> On Wed, Oct 5, 2011 at 2:58 PM, Kohei KaiGai wrote:
>>> Hmm. It indeed makes translation hard.
>>> I reverted this portion of the part-2 patch, as attached.
>>> Please review the newer one, instead of the previous
2011/10/10 Robert Haas :
> On Wed, Oct 5, 2011 at 2:58 PM, Kohei KaiGai wrote:
>> Hmm. It indeed makes translation hard.
>> I reverted this portion of the part-2 patch, as attached.
>> Please review the newer one, instead of the previous revision.
>
> Please fix the compiler warnings.
>
I checked
On Wed, Oct 5, 2011 at 2:58 PM, Kohei KaiGai wrote:
> Hmm. It indeed makes translation hard.
> I reverted this portion of the part-2 patch, as attached.
> Please review the newer one, instead of the previous revision.
Please fix the compiler warnings.
--
Robert Haas
EnterpriseDB: http://www.ent
On Wed, Oct 5, 2011 at 12:16 PM, Kohei KaiGai wrote:
> * The logic of check_object_validation() got included within
> get_relation_address(), and rewritten more smartly, as:
>
> + relkind = RelationGetForm(relation)->relkind;
> + if ((objtype == OBJECT_INDEX && relkind != RELKIND_INDE
On Wed, Oct 5, 2011 at 4:47 AM, Kohei KaiGai wrote:
> The get_relation_address() follows the logic in RemoveRelations() to be
> eliminated by this patch, so it is not a code duplication.
> The reason why we didn't consolidate this routine with get_object_address()
> was that remove-index requires
Thanks for your reviewing.
2011/10/4 Robert Haas :
> On Wed, Sep 28, 2011 at 11:51 AM, Kohei KaiGai wrote:
>> I rebased the patches towards the latest git master, so I believe these
>> are available to apply.
>
> Reviewing away...
>
> I don't see why we need one struct called ObjectProperty and a
On Wed, Sep 28, 2011 at 11:51 AM, Kohei KaiGai wrote:
> I rebased the patches towards the latest git master, so I believe these
> are available to apply.
Reviewing away...
I don't see why we need one struct called ObjectProperty and another
called CatalogProperty. Just fold CatalogProperty into
On Mon, Oct 3, 2011 at 11:28 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Oct 3, 2011 at 10:54 AM, Dimitri Fontaine
>> wrote:
>>> Robert Haas writes:
I think that new versions of patch can handle unified diffs without a
problem, but older versions choke on them. My Mac has 2.
Robert Haas writes:
> Yeah, it just skips right over them. I've never had even a minor
> problem on that account, which is why I was surprised to see it giving
> you so much trouble.
Ok then, I'll try some more next time. Been trying not to spend too
much time here… on the other hand git apply
Excerpts from Dimitri Fontaine's message of lun oct 03 11:54:36 -0300 2011:
> Robert Haas writes:
> > I think that new versions of patch can handle unified diffs without a
> > problem, but older versions choke on them. My Mac has 2.5.8 and
> > handles unidiffs no problem.
>
> Even containing gi
Robert Haas writes:
> On Mon, Oct 3, 2011 at 10:54 AM, Dimitri Fontaine
> wrote:
>> Robert Haas writes:
>>> I think that new versions of patch can handle unified diffs without a
>>> problem, but older versions choke on them. My Mac has 2.5.8 and
>>> handles unidiffs no problem.
>> Even contain
On Mon, Oct 3, 2011 at 10:54 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> I think that new versions of patch can handle unified diffs without a
>> problem, but older versions choke on them. My Mac has 2.5.8 and
>> handles unidiffs no problem.
>
> Even containing git headers?
Yeah, it ju
Robert Haas writes:
> I think that new versions of patch can handle unified diffs without a
> problem, but older versions choke on them. My Mac has 2.5.8 and
> handles unidiffs no problem.
Even containing git headers?
Here's what I'm talking about here:
src/backend/catalog/objectaddress.c |
On Sun, Oct 2, 2011 at 4:08 PM, Dimitri Fontaine wrote:
> Ok I needed `git apply' to apply the patches, now that I used that I can
> confirm that the 3 patches apply, compile, pass tests, and that I could
> play with them a little. I think I'm going to mark that ready for
> commiter. I don't hav
Hi,
Kohei KaiGai writes:
>> I've been reviewing those patches, that are all about code refactoring.
>> I like what it's doing, generalizing ad-hoc code by adding some more
>> knowledge about the source tree into some data structures. Typically,
>> what catcache to use for a given object's class-
Dimitri Fontaine writes:
> The patches are not in git am format nor in patch format, so I could
> only read them, I didn't install them nor compiled the code, didn't run
> the regression tests.
I've marked the patch as Waiting on Author and referred to my previous
message. Thanks,
--
Dimitri F
Hi,
Kohei KaiGai writes:
> 2011/8/15 Kohei KaiGai :
>> The attached three patches try to consolidate code path of DROP
>> statement on various kind of object classes.
>
> These are rebased to the latest tree, and the part-3 portion also consolidates
> DROP OPERATOR FAMILY/CLASS routines that I fo
28 matches
Mail list logo
