Re: dealing with extension dependencies that aren't quite 'e'
От | Alvaro Herrera |
---|---|
Тема | Re: dealing with extension dependencies that aren't quite 'e' |
Дата | |
Msg-id | 20160404215503.GA237481@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: dealing with extension dependencies that aren't quite 'e' (Abhijit Menon-Sen <ams@2ndQuadrant.com>) |
Ответы |
Re: dealing with extension dependencies that aren't quite 'e'
|
Список | pgsql-hackers |
Abhijit Menon-Sen wrote: > At 2016-03-29 10:15:51 -0400, david@pgmasters.net wrote: > > > > Either way it looks like you need to post a patch with more > > documentation - do you know when you'll have that ready? > > Here it is. > > (I was actually looking for other potential callers, but I couldn't find > any. There are some places that take a RangeVar and make a list from it, > but they are creating new nodes, and don't quite fit. So the only change > in this patch is to add a comment above the get_object_address_rv > function.) I gave this another look. To test whether the grammar is good, I tried a few additional object cases. They all seem to work fine, provided that we use the same production for the object name as in the corresponding ALTER <foo> case for the object. The attached is simply an extension with those new grammar rules -- I didn't go beyond ensuring the new productions didn't cause any conflicts. (I also removed the new includes in alter.c, which are no longer necessary AFAICS.) At this point I think we're missing user-level docs for the additional clause in each ALTER command. I think it's a fiddly business, because each individual ALTER page is going to need to be touched for the new clause, but that can't be avoided. Do you have any ideas on how this would appear in regression tests? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: