Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Do we need a struct, or can we get away with storing the values directly
> in RelationData? Something like this:
The intention behind having a separate struct was that there could
possibly be different sets of reloptions for different types of
relation
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I've already modified your patch a bit ... please send your updated
> > patch so I can merge it into mine. However, my changes were also
> > relatively minor. Since Tom wants it to be entirely rewritten then
> > maybe merging minor
Euler Taveira de Oliveira wrote:
> Alvaro Herrera escreveu:
>
> > I've already modified your patch a bit ... please send your updated
> > patch so I can merge it into mine. However, my changes were also
> > relatively minor. Since Tom wants it to be entirely rewritten then
> > maybe merging mino
Alvaro Herrera escreveu:
> I've already modified your patch a bit ... please send your updated
> patch so I can merge it into mine. However, my changes were also
> relatively minor. Since Tom wants it to be entirely rewritten then
> maybe merging minor fixes to it is a waste of time ...
>
Since
I wrote:
> The thing I'm complaining about is having dropped the intermediate
> struct that represents the fully decoded set of reloptions.
After looking at the patch a bit more I have a couple of other comments:
* I disagree with changing the argument of the RelationGetXXX
macros from Relation t
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I've already modified your patch a bit ... please send your updated
> patch so I can merge it into mine. However, my changes were also
> relatively minor. Since Tom wants it to be entirely rewritten then
> maybe merging minor fixes to it is a waste of
Euler Taveira de Oliveira wrote:
> Tom Lane escreveu:
>
> > Hmm ... I'd not looked at that patch before, but now that I have I think
> > it's gone pretty seriously off on the overdesigned-and-inefficient end
> > of the spectrum. Turning RelationGetFillFactor and friends from simple
> > macros int
Tom Lane escreveu:
> Hmm ... I'd not looked at that patch before, but now that I have I think
> it's gone pretty seriously off on the overdesigned-and-inefficient end
> of the spectrum. Turning RelationGetFillFactor and friends from simple
> macros into functions that are probably *at least* a th
Alvaro Herrera escreveu:
> The reloptions patch uses three arrays, one for each type of option
> (bool, int, float). I'm wondering if we could use a single array with
> all options, and a union containing the values. The only problem with
> that (AFAICS) is the initialization.
>
I already tried
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Where/why do you need to do that?
> The reloptions patch uses three arrays, one for each type of option
> (bool, int, float). I'm wondering if we could use a single array with
> all options, and a union containing the values. The on
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I mean something like this:
>
> Where/why do you need to do that?
The reloptions patch uses three arrays, one for each type of option
(bool, int, float). I'm wondering if we could use a single array with
all options, and a union c
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I wonder how portable designated initializers are. As far as I can tell
> they were only defined in C99. Can we use them in our source?
I'd vote no. We're still targeting ANSI C (eg, no // comments).
> I mean something like this:
Where/why do you n
Hi,
I wonder how portable designated initializers are. As far as I can tell
they were only defined in C99. Can we use them in our source? If not,
is there a way to do this in C89?
I mean something like this:
typedef struct foo {
chartype;
union {
int iv
13 matches
Mail list logo
