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 fixes to
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
relations,
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 minor fixes
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 to
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
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 need
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
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 only
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
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
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 into
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 time
13 matches
Mail list logo
