Re: WIP: generalized index constraints
От | Jeff Davis |
---|---|
Тема | Re: WIP: generalized index constraints |
Дата | |
Msg-id | 1253386314.23353.69.camel@jdavis обсуждение исходный текст |
Ответ на | Re: WIP: generalized index constraints (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: WIP: generalized index constraints
Re: WIP: generalized index constraints |
Список | pgsql-hackers |
On Sat, 2009-09-19 at 14:05 -0400, Tom Lane wrote: > What about them? It's not clear why you think this requires anything > special. >From a syntax standpoint, I need to represent one operator for every index column involved in the constraint. So, if there's a functional index on ((a||b)::circle), I clearly can't have an exclusion constraint like (a =, b =). I see two options: 1. (<expr> <op>), where <expr> is an expression over table attributes that must have the exact signature as the expressionfor the index.2. (<index_col> <op>), and then read the expression from the index and in either case, use that expression for the extra checking that I need to do: I need to check whether the input heap tuple conflicts with concurrently inserting heap tuples, and I also need to do a recheck step. #1 seems like extra work and complexity, because I need to test for the correct signature (maybe that's not difficult), and that extra flexibility is pretty marginal -- I can't think of an obvious case where you'd want different expressions. Also, it complicates the simple case of wanting the expressions to match. #2 is awkward because the expression columns of an index have generated names, and you would have to write things like (pg_expression_1 &&). Also, it makes the constraint too tied to the index, which is a valid complaint Peter had. Perhaps you can point me in the right direction to see if two expressions/functions have matching signatures? Or, if that is too much of a pain, perhaps I should just test for equal expressions? Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: