Re: lock listing
| От | nconway@klamath.dyndns.org (Neil Conway) |
|---|---|
| Тема | Re: lock listing |
| Дата | |
| Msg-id | 20020722160255.GA3001@klamath.dyndns.org обсуждение |
| Ответ на | Re: lock listing (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: lock listing
|
| Список | pgsql-patches |
On Fri, Jul 19, 2002 at 05:15:43PM -0400, Tom Lane wrote: > nconway@klamath.dyndns.org (Neil Conway) writes: > > On Fri, Jul 19, 2002 at 01:21:10PM -0400, Tom Lane wrote: > >> I'm very unthrilled with this approach to faking up a composite type > >> for pg_show_locks to return. > > > As am I, and I agree that the proper long-term answer is some new > > infrastructure for adding builtin SRFs. However, I don't think that's > > a really good reason for rejecting the patch -- > > I'm not wanting to reject the patch; I'm wanting to restructure it as > additions to lmgr.c plus a contrib module that includes the API function > and perhaps some sample views. The contrib module's install script > could avoid these pesky problems because it can just CREATE a dummy > table or view and then CREATE the function. Once we have a better > answer about declaring built-in SRFs, we can migrate the code into the > core. Personally, that doesn't strike me as a lot cleaner than just putting the code into the core in the first place. Since the changes to adapt the SRF to a new composite type scheme would be trivial (less than 20 lines of changes, probably less), I'd personally vote to include it in the core, and put up with a little bit of ugliness in initdb until we get a proper solution. I've attached a revised patch which incorporates Tom's suggestions, as well as including a few more code cleanups/fixes, and doesn't remove the USER_LOCKS code. Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
Вложения
В списке pgsql-patches по дате отправления: