Re: currawong is not a happy animal
От | Andrew Dunstan |
---|---|
Тема | Re: currawong is not a happy animal |
Дата | |
Msg-id | 52D99E0E.7060103@dunslane.net обсуждение исходный текст |
Ответ на | Re: currawong is not a happy animal (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: currawong is not a happy animal
|
Список | pgsql-hackers |
On 01/17/2014 03:15 PM, Tom Lane wrote: > The other possibility I was contemplating is that "export a const > variable" doesn't actually work for some reason. We're not in the habit > of doing that elsewhere, so I don't find that theory outlandish. Perhaps > it could be fixed by adding PGDLLIMPORT to the extern, but on the whole > I'd rather avoid the technique altogether. > > The least-unlike-other-Postgres-code approach would be to go ahead and > export the struct so that the size computation could be provided as a > #define in the same header. Robert stated a couple days ago that he > didn't foresee much churn in this struct, so that doesn't seem > unacceptable. > > Another possibility is to refactor so that testing an allocation request > against shm_mq_minimum_size is the responsibility of storage/ipc/shm_mq.c, > not some random code in a contrib module. It's not immediately apparent > to me why it's good code modularization to have a contrib module > responsible for checking sizes based on the sizeof a struct it's not > supposed to have any access to. > > Or maybe we could expose the value via a function rather than a const variable. cheers andrew
В списке pgsql-hackers по дате отправления: