Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail
| От | Michael Paquier |
|---|---|
| Тема | Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail |
| Дата | |
| Msg-id | 20190725103113.GB10546@paquier.xyz обсуждение исходный текст |
| Ответ на | Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail
|
| Список | pgsql-bugs |
On Tue, Jul 23, 2019 at 01:28:38PM +0900, Michael Paquier wrote: > Okay. Sharing a maximum the build of IndexInfo done as part of > DefineIndex is something that we should do then. Attached is a patch > that I have been working on, introducing a new makeIndexInfo() in > makefuncs.c. Still as IndexInfo is not a parse node but an exec node, > I am including execnodes.h in makefuncs.h for now (perhaps somebody > has a better idea?). This fills the index information of the new > entry directly from the catalog of the old entry for expressions and > predicates. I have been looking at this code today and extended the test cases with more expression and predicate indexes to stress more the patch, and it happens that I am still stuck for with makeIndexInfo(). The header comments of makefuncs.h and makefuncs.c mention primitive nodes, so I would need at least to update that part to mention execution nodes. Still I'd rather not have people scream at me as that could be considered invasive in terms of included dependencies for makefuncs.c :) If we don't have the makeIndexInfo wrapper, please note that we finish by filling in three times IndexInfo with roughly the same data in different places, so I would like to keep it. So, are there any opinions or ideas about that? -- Michael
Вложения
В списке pgsql-bugs по дате отправления: