Re: WIP: generalized index constraints

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: WIP: generalized index constraints
Дата
Msg-id 1252920839.32345.549.camel@jdavis
обсуждение исходный текст
Ответ на Re: WIP: generalized index constraints  (Brendan Jurd <direvus@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: opportunistic tuple freezing
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Resjunk sort columns, Heikki's index-only quals patch, and bug #5000