Re: currawong is not a happy animal - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: currawong is not a happy animal
Date
Msg-id 52D99E0E.7060103@dunslane.net
Whole thread Raw
In response to Re: currawong is not a happy animal  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: currawong is not a happy animal  (Amit Kapila <amit.kapila16@gmail.com>)
List 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 by date:

Previous
From: Florian Pflug
Date:
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Next
From: David Rowley
Date:
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)