From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: currawong is not a happy animal |
Date: | 2014-01-17 21:18:06 |
Message-ID: | 52D99E0E.7060103@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2014-01-17 21:42:39 | Re: [PATCH] Negative Transition Aggregate Functions (WIP) |
Previous Message | Florian Pflug | 2014-01-17 21:17:02 | Re: [PATCH] Negative Transition Aggregate Functions (WIP) |