Re: WIP: generalized index constraints - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: WIP: generalized index constraints
Date
Msg-id 1252920839.32345.549.camel@jdavis
Whole thread Raw
In response to Re: WIP: generalized index constraints  (Brendan Jurd <direvus@gmail.com>)
List pgsql-hackers
On Sun, 2009-09-13 at 19:08 +1000, Brendan Jurd wrote:
> The September CF starts in a couple of days, so this patch is in
> danger of missing the boat.

Thanks for keeping track. I accomplished a significant amount today, so
there's still hope for 9/15.

I will most likely just focus on the core functionality so that I have
something complete and reviewable.

> The unresolved points seem to be:
> 
>  * What to do about INCLUDING INDEXES EXCLUDING CONSTRAINTS --
> Postgres gets this wrong for unique indexes currently.  Should we
> persist with the existing behaviour or fix it as part of this patch?
> My personal feeling was +1 for fixing it in this patch.

I don't think that it should make a difference whether "EXCLUDING
CONSTRAINTS" is specified or omitted. There is no "[INCLUDING|EXCLUDING]
CONSTRAINTS" option in the standard, but for the other LIKE options,
EXCLUDING is implied when INCLUDING is not specified.

So, I think we have to make a decision:1. If INCLUDING CONSTRAINTS is specified, but not INCLUDING INDEXES,   do we:
copythe indexes silently; or emit a nice message; or throw    an ERROR?2. What if INCLUDING INDEXES is specified, but
notINCLUDING    CONSTRAINTS?
 

>  * Should we emit some sort of message when the user specifies
> INCLUDING INDEXES or INCLUDING CONSTRAINTS but not both?  I didn't
> have strong feelings about this one but there was some differing
> thoughts about what log level to use.  I thought NOTICE but Alvaro
> reckons we've got too many of those already.  Tom mentioned the
> suggested (but unimplemented) NOVICE level, which seems like a good
> move but doesn't resolve the problem of what to do in this patch.  One
> option would be to add a message at the NOTICE level with a TODO to
> downgrade it to NOVICE if/when that becomes available.

I don't think either of these things are a huge amount of work; they are
mostly just decisions that need to be made. I'll start off implementing
whatever is easiest/cleanest, and we'll continue the discussion.

Regards,Jeff Davis





pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: opportunistic tuple freezing
Next
From: Heikki Linnakangas
Date:
Subject: Re: Resjunk sort columns, Heikki's index-only quals patch, and bug #5000