Skip site navigation (1) Skip section navigation (2)

Re: generic reloptions improvement

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Subject: Re: generic reloptions improvement
Date: 2009-01-04 21:31:08
Message-ID: 20090104213108.GD26552@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
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 minor correction.
Warning: I intend to commit this patch fairly soon!

As far as I can see, the new code can work with the options you've
defined in the SEPgsql code just fine.  Handling string options in
itself is fine; the complexity (as I already said) is in allocating
memory for the string if you want to store it unchanged in the bytea
stuff in relcache.  Since you're not storing the string itself but
convert it to an Oid, there's no problem.

Actually, storing the string itself works fine as long as you have a
single one, because you can define the option struct like this:

/* must follow StdRdOptions conventions */
typedef struct BtOptions
{
	int32	vl_len_;
	int		fillfactor;
	char	teststring[1];
} BtOptions;

and there are no pointers involved.  This doesn't work:

typedef struct BtOptions
{
	int32	vl_len_;
	int		fillfactor;
	char	*teststring;
} BtOptions;

because then there's a pointer, and it fails as soon as the bytea * is
copied by the relcache code.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Attachment: relopt-7a.patch
Description: text/x-diff (321 bytes)

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2009-01-04 21:36:11
Subject: Re: generic reloptions improvement
Previous:From: Joe ConwayDate: 2009-01-04 20:34:14
Subject: dblink vs SQL/MED - security and implementation details

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group