Heikki Linnakangas writes:
> On 09.08.2011 18:04, Alvaro Herrera wrote:
>> I think I vaguely remember that the reason for doing it this way is that
>> the copy into the relcache worked, i.e. if the originals went away,
>> there was no dangling pointer. Did you test this?
> These strings are neve
On 09.08.2011 18:04, Alvaro Herrera wrote:
Excerpts from Heikki Linnakangas's message of mar ago 09 08:32:43 -0400 2011:
On 09.08.2011 13:25, Heikki Linnakangas wrote:
On 08.08.2011 22:11, Alvaro Herrera wrote:
Perhaps the easiest way to fix it is as you suggest, by declaring the
struct to tak
Excerpts from Heikki Linnakangas's message of mar ago 09 08:32:43 -0400 2011:
> On 09.08.2011 13:25, Heikki Linnakangas wrote:
> > On 08.08.2011 22:11, Alvaro Herrera wrote:
> >> Perhaps the easiest way to fix it is as you suggest, by declaring the
> >> struct to take a pointer rather than the valu
On 09.08.2011 13:25, Heikki Linnakangas wrote:
On 08.08.2011 22:11, Alvaro Herrera wrote:
Perhaps the easiest way to fix it is as you suggest, by declaring the
struct to take a pointer rather than the value directly. Not sure how
to make both cases work sanely; the add_string_reloption path will
On 08.08.2011 22:11, Alvaro Herrera wrote:
Perhaps the easiest way to fix it is as you suggest, by declaring the
struct to take a pointer rather than the value directly. Not sure how
to make both cases work sanely; the add_string_reloption path will need
updates.
Agreed, I propose the attached
Excerpts from Alexander Korotkov's message of lun ago 08 13:21:17 -0400 2011:
> On Mon, Aug 8, 2011 at 8:27 PM, Alvaro Herrera
> wrote:
>
> > An array of relopt_string? Isn't that a bit strange? If I recall
> > correctly, the point of this was to be able to allocate the
> > relopt_string struct
On Mon, Aug 8, 2011 at 8:27 PM, Alvaro Herrera
wrote:
> An array of relopt_string? Isn't that a bit strange? If I recall
> correctly, the point of this was to be able to allocate the
> relopt_string struct and the char array itself as a single palloc unit,
> in a single call somewhere in the rel
Excerpts from Alexander Korotkov's message of lun ago 08 11:50:53 -0400 2011:
> On Mon, Aug 8, 2011 at 7:43 PM, Alvaro Herrera
> wrote:
>
> > Maybe this needs to use the new FLEXIBLE_ARRAY_MEMBER stuff. Can you try
> > that please?
>
>
> typedef struct relopt_string
> {
> relopt_gen gen;
> int
On Mon, Aug 8, 2011 at 7:43 PM, Alvaro Herrera
wrote:
> Maybe this needs to use the new FLEXIBLE_ARRAY_MEMBER stuff. Can you try
> that please?
typedef struct relopt_string
{
relopt_gen gen;
int default_len;
bool default_isnull;
validate_string_relopt validate_cb;
char default_val[1]; /* vari
Excerpts from Alexander Korotkov's message of lun ago 08 06:27:33 -0400 2011:
> String-formatted relopts was never used before, but I've used it in
> buffering GiST index build patch and encountered with following compiler
> warnings:
>
> reloptions.c:259: warning: initializer-string for array of
String-formatted relopts was never used before, but I've used it in
buffering GiST index build patch and encountered with following compiler
warnings:
reloptions.c:259: warning: initializer-string for array of chars is too long
reloptions.c:259: warning: (near initialization for
‘stringRelOpts[0].
11 matches
Mail list logo
