KaiGai Kohei wrote:
> If the caller allocates a surplus area to store string on tail of the
> StdRdOptions (or others), the string option can be represented as an
> offset value and should be accessed via macros, like:
Excellent. I thought about storing an offset but I didn't know how to
make it
Alvaro Herrera wrote:
> KaiGai Kohei wrote:
>
>> (1) Who/Where should allocate a string area?
>>
>> + /* Note that this assumes that the variable is already allocated! */
>> + #define HANDLE_STRING_RELOPTION(optname, var, option) \
>> + if (HAVE_RELOPTION(optname, option))
Alex Hunsaker escribió:
> On Sun, Jan 4, 2009 at 15:01, Alvaro Herrera
> wrote:
> > Alvaro Herrera wrote:
> >
> >> Okay, it was basically fine except for the attached minor correction.
> >> Warning: I intend to commit this patch fairly soon!
> >
> > This is the patch in its final form. I have in
KaiGai Kohei wrote:
> (1) Who/Where should allocate a string area?
>
> + /* Note that this assumes that the variable is already allocated! */
> + #define HANDLE_STRING_RELOPTION(optname, var, option) \
> + if (HAVE_RELOPTION(optname, option))\
> +
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
>> Okay, it was basically fine except for the attached minor correction.
>> Warning: I intend to commit this patch fairly soon!
>
> This is the patch in its final form. I have included a few macros to
> simplify the writing of amoptions routines.
Alvaro Herrera writes:
> This is the patch in its final form. I have included a few macros to
> simplify the writing of amoptions routines.
Minor gripes:
* Does initialize_reloptions() need to be exported? It seems to be
only called within parseRelOptions(). It's far from clear who else
shoul
On Sun, Jan 4, 2009 at 15:01, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
>> Okay, it was basically fine except for the attached minor correction.
>> Warning: I intend to commit this patch fairly soon!
>
> This is the patch in its final form. I have included a few macros to
> simplify the wri
Alvaro Herrera wrote:
> Okay, it was basically fine except for the attached minor correction.
> Warning: I intend to commit this patch fairly soon!
This is the patch in its final form. I have included a few macros to
simplify the writing of amoptions routines.
--
Alvaro Herrera
Simon Riggs wrote:
> Custom variable classes are often useful, but they are system wide. It
> would be good to be able to use table-level options and have them work
> very similarly to something we already have. Table-level options are
> just an obvious "normalisation" of how we handle parameters.
Alvaro Herrera wrote:
> Some notes about this patch:
>
> - the string type handling (basically all the new code) is untested.
> I'll have a look tomorrow at the btree test code I sent the other day to
> add a string option and see how it goes.
Okay, it was basically fine except for the attached
KaiGai Kohei wrote:
> If it is provided for v8.4, I'm happy at least.
> The Row-level ACLs need its reloption to specify default ACLs in string
> expression. Currently, it modifies "reloptions.c", but using it on common
> framework will be more appropriate implementation.
Modified to add a string
Simon Riggs wrote:
> If you really can't see a use for this, OK, then: Please can you put in
> a plugin API for user defined reloptions as well as what you are
> proposing. We discussed this before in late July/early Aug on thread
> "Uncopied parameters..."
Hmm, I was just looking at the CREATE
KaiGai Kohei wrote:
> Alvaro Herrera wrote:
>> No, it doesn't. I asked about it some time ago and nobody answered. If
>> people feel it is important, I can implement it.
>
> Oh, I missed to see the message.
>
> If it is provided for v8.4, I'm happy at least.
> The Row-level ACLs need its relopti
Alvaro Herrera wrote:
KaiGai Kohei wrote:
Alvaro Herrera wrote:
So this is an updated patch. This now allows a user-defined AM to
create new reloptions and pass them down to the parser for parsing and
checking.
This patch does not support reloptions in string expression, like:
No, it does
On Sat, 2009-01-03 at 12:20 -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
> > I very much like the idea of adding new/custom options to tables. There
> > are many uses for that.
>
> Hmm, like what? I'm not sure how would it work for tables; you'd have
> to add the options during _PG_init
Simon Riggs wrote:
> I very much like the idea of adding new/custom options to tables. There
> are many uses for that.
Hmm, like what? I'm not sure how would it work for tables; you'd have
to add the options during _PG_init or something like that, and I haven't
tried it. It's mainly for user-de
KaiGai Kohei wrote:
> Alvaro Herrera wrote:
> > So this is an updated patch. This now allows a user-defined AM to
> > create new reloptions and pass them down to the parser for parsing and
> > checking.
>
> This patch does not support reloptions in string expression, like:
No, it doesn't. I as
On Tue, 2008-12-30 at 12:31 -0300, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > Tom Lane wrote:
> > > Alvaro Herrera writes:
> >
> > > > I'm intending to have a new routine which would reserve a value at
> > > > runtime. This value would be later be passed by the AM to create new
> > > > o
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> Alvaro Herrera writes:
I'm intending to have a new routine which would reserve a value at
runtime. This value would be later be passed by the AM to create new
options on the table.
>>> What do you mean by "at runt
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera writes:
>
> > > I'm intending to have a new routine which would reserve a value at
> > > runtime. This value would be later be passed by the AM to create new
> > > options on the table.
> >
> > What do you mean by "at runtime"? Surely
Tom Lane wrote:
> Alvaro Herrera writes:
> > I'm intending to have a new routine which would reserve a value at
> > runtime. This value would be later be passed by the AM to create new
> > options on the table.
>
> What do you mean by "at runtime"? Surely the value would have to remain
> stabl
Alvaro Herrera writes:
> Peter Eisentraut wrote:
>> I'm not sure how important this is, but if you are enumerating the access
>> methods (RELOPT_KIND_BTREE, etc.), how will this work with user-defined
>> access methods?
> It is important.
> I'm intending to have a new routine which would reser
Peter Eisentraut wrote:
> I'm not sure how important this is, but if you are enumerating the access
> methods (RELOPT_KIND_BTREE, etc.), how will this work with user-defined
> access methods?
It is important.
I'm intending to have a new routine which would reserve a value at
runtime. This val
On Monday 22 December 2008 18:24:53 Alvaro Herrera wrote:
> > Alvaro Herrera wrote:
> > > Here's a patch for improving the general reloptions mechanism. What
> > > this patch does is add a table-based option parser. This allows adding
> > > new options very easily, and stops the business of havi
ITAGAKI Takahiro wrote:
> Alvaro Herrera wrote:
>
> > Here's a patch for improving the general reloptions mechanism. What
> > this patch does is add a table-based option parser. This allows adding
> > new options very easily, and stops the business of having to pass the
> > minimum and default
Hi, I have a comment about the generic-reloptions patch.
Alvaro Herrera wrote:
> Here's a patch for improving the general reloptions mechanism. What
> this patch does is add a table-based option parser. This allows adding
> new options very easily, and stops the business of having to pass the
A small correction to this patch: this is needed because otherwise the
autovac code to parse the option becomes all tangled; this avoids having
to invent special values for "use the default value", and it also avoid
having the default value stored elsewhere in the code than in the
reloptions table.
27 matches
Mail list logo
