Re: CREATE TABLE LIKE INCLUDING INDEXES support
От | Alvaro Herrera |
---|---|
Тема | Re: CREATE TABLE LIKE INCLUDING INDEXES support |
Дата | |
Msg-id | 20070523142442.GL4642@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: CREATE TABLE LIKE INCLUDING INDEXES support (NikhilS <nikkhils@gmail.com>) |
Ответы |
Re: CREATE TABLE LIKE INCLUDING INDEXES support
Re: CREATE TABLE LIKE INCLUDING INDEXES support |
Список | pgsql-patches |
NikhilS escribió: > On 5/23/07, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > >NikhilS <nikkhils@gmail.com> writes: > >> If so, I think we can introduce 2 Oid fields in the IndexStmt > >> structure and store the Oids there. In DefineIndex we can use these > >> Oids if they are not invalid. > > > >I think this is just make-work that causes the patch to complicate parts > >of the system it didn't need to touch. The original suggestion was to > >actively refactor existing code, which might or might not have been > >worthwhile. But this isn't an appropriate substitute --- it's just > >making the API uglier for no particular benefit. > > I agree this will unnecessary add arguments to the DefineIndex API. If we > stick to the patch's earlier way of converting the Oid to names for just > these 2 arguments, we can avoid this IMO. > > Considering that we will be generating this information from existing valid > index information, I think converting the Oids to names is safe enough. > Alvaro, do you think we should stick to the existing patch mechanism then > considering that it avoids polluting the API? Not sure. Is it possible that the schema is renamed while the operation is being executed? If it's not then this not a problem at all so the existing patch is fine. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-patches по дате отправления: