pgsql: Allow units to be specified in relation option setting value.

Started by Fujii Masaoover 11 years ago12 messages
#1Fujii Masao
fujii@postgresql.org

Allow units to be specified in relation option setting value.

This introduces an infrastructure which allows us to specify the units
like ms (milliseconds) in integer relation option, like GUC parameter.
Currently only autovacuum_vacuum_cost_delay reloption can accept
the units.

Reviewed by Michael Paquier

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/e23014f3d40f7d2c23bc97207fd28efbe5ba102b

Modified Files
--------------
src/backend/access/common/reloptions.c | 40 ++++++++++++++++-------------
src/include/access/reloptions.h | 3 ++-
src/test/regress/expected/alter_table.out | 14 ++++++++++
src/test/regress/sql/alter_table.sql | 6 +++++
4 files changed, 44 insertions(+), 19 deletions(-)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

#2Andres Freund
andres@2ndquadrant.com
In reply to: Fujii Masao (#1)
Re: pgsql: Allow units to be specified in relation option setting value.

Hi,

On 2014-08-28 07:15:35 +0000, Fujii Masao wrote:

Allow units to be specified in relation option setting value.

This introduces an infrastructure which allows us to specify the units
like ms (milliseconds) in integer relation option, like GUC parameter.
Currently only autovacuum_vacuum_cost_delay reloption can accept
the units.

This apparently broke pg_upgrade. I've not checked what's up there.

See
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2014-08-28%2007%3A16%3A04
and many others.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

#3Fujii Masao
masao.fujii@gmail.com
In reply to: Andres Freund (#2)
Re: pgsql: Allow units to be specified in relation option setting value.

On Thu, Aug 28, 2014 at 9:11 PM, Andres Freund <andres@2ndquadrant.com> wrote:

Hi,

On 2014-08-28 07:15:35 +0000, Fujii Masao wrote:

Allow units to be specified in relation option setting value.

This introduces an infrastructure which allows us to specify the units
like ms (milliseconds) in integer relation option, like GUC parameter.
Currently only autovacuum_vacuum_cost_delay reloption can accept
the units.

This apparently broke pg_upgrade. I've not checked what's up there.

See
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&amp;dt=2014-08-28%2007%3A16%3A04
and many others.

Oh,, will check.

Regards,

--
Fujii Masao

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

#4Michael Paquier
michael.paquier@gmail.com
In reply to: Fujii Masao (#3)
Re: pgsql: Allow units to be specified in relation option setting value.

On Thu, Aug 28, 2014 at 9:28 PM, Fujii Masao <masao.fujii@gmail.com> wrote:

Oh,, will check.

That's a problem with pg_dump not able to put quotes where for a
reloption units are used.
For example this table:
create table test (a int) with (autovacuum_vacuum_cost_delay = '80ms');
Results in the following dump:
CREATE TABLE test (
a integer
)
WITH (autovacuum_vacuum_cost_delay=80ms);

Because of how reloptions is registered in pg_class:
=# select relname,reloptions from pg_class where relname = 'test';
relname | reloptions
---------+-------------------------------------
test | {autovacuum_vacuum_cost_delay=80ms}
(1 row)
Regards,
--
Michael

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

#5Michael Paquier
michael.paquier@gmail.com
In reply to: Michael Paquier (#4)
1 attachment(s)
Re: pgsql: Allow units to be specified in relation option setting value.

On Thu, Aug 28, 2014 at 10:51 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:

Because of how reloptions is registered in pg_class:

The patch attached fixes pg_upgrade by putting quotes when generating
reloptions and it passes check-world. I imagine that having quotes by
default in the value of reloptions in pg_class is the price to pay for
supporting units. If this is not considered as a correct approach,
then reverting the patch would be wiser I guess.
Regards,
--
Michael

Attachments:

20140828_relopt_unit_fix.patchtext/x-diff; charset=US-ASCII; name=20140828_relopt_unit_fix.patchDownload
*** a/contrib/test_decoding/expected/ddl.out
--- b/contrib/test_decoding/expected/ddl.out
***************
*** 345,351 **** WITH (user_catalog_table = true)
   options  | text[]  |                                                                   | extended |              | 
  Indexes:
      "replication_metadata_pkey" PRIMARY KEY, btree (id)
! Options: user_catalog_table=true
  
  INSERT INTO replication_metadata(relation, options)
  VALUES ('foo', ARRAY['a', 'b']);
--- 345,351 ----
   options  | text[]  |                                                                   | extended |              | 
  Indexes:
      "replication_metadata_pkey" PRIMARY KEY, btree (id)
! Options: user_catalog_table='true'
  
  INSERT INTO replication_metadata(relation, options)
  VALUES ('foo', ARRAY['a', 'b']);
***************
*** 372,378 **** ALTER TABLE replication_metadata SET (user_catalog_table = true);
   options  | text[]  |                                                                   | extended |              | 
  Indexes:
      "replication_metadata_pkey" PRIMARY KEY, btree (id)
! Options: user_catalog_table=true
  
  INSERT INTO replication_metadata(relation, options)
  VALUES ('blub', NULL);
--- 372,378 ----
   options  | text[]  |                                                                   | extended |              | 
  Indexes:
      "replication_metadata_pkey" PRIMARY KEY, btree (id)
! Options: user_catalog_table='true'
  
  INSERT INTO replication_metadata(relation, options)
  VALUES ('blub', NULL);
***************
*** 391,397 **** ALTER TABLE replication_metadata SET (user_catalog_table = false);
   rewritemeornot | integer |                                                                   | plain    |              | 
  Indexes:
      "replication_metadata_pkey" PRIMARY KEY, btree (id)
! Options: user_catalog_table=false
  
  INSERT INTO replication_metadata(relation, options)
  VALUES ('zaphod', NULL);
--- 391,397 ----
   rewritemeornot | integer |                                                                   | plain    |              | 
  Indexes:
      "replication_metadata_pkey" PRIMARY KEY, btree (id)
! Options: user_catalog_table='false'
  
  INSERT INTO replication_metadata(relation, options)
  VALUES ('zaphod', NULL);
*** a/src/backend/access/common/reloptions.c
--- b/src/backend/access/common/reloptions.c
***************
*** 728,734 **** transformRelOptions(Datum oldOptions, List *defList, char *namspace,
  				continue;
  
  			/*
! 			 * Flatten the DefElem into a text string like "name=arg". If we
  			 * have just "name", assume "name=true" is meant.  Note: the
  			 * namespace is not output.
  			 */
--- 728,734 ----
  				continue;
  
  			/*
! 			 * Flatten the DefElem into a text string like "name='arg'". If we
  			 * have just "name", assume "name=true" is meant.  Note: the
  			 * namespace is not output.
  			 */
***************
*** 736,746 **** transformRelOptions(Datum oldOptions, List *defList, char *namspace,
  				value = defGetString(def);
  			else
  				value = "true";
! 			len = VARHDRSZ + strlen(def->defname) + 1 + strlen(value);
  			/* +1 leaves room for sprintf's trailing null */
  			t = (text *) palloc(len + 1);
  			SET_VARSIZE(t, len);
! 			sprintf(VARDATA(t), "%s=%s", def->defname, value);
  
  			astate = accumArrayResult(astate, PointerGetDatum(t),
  									  false, TEXTOID,
--- 736,746 ----
  				value = defGetString(def);
  			else
  				value = "true";
! 			len = VARHDRSZ + strlen(def->defname) + 3 + strlen(value);
  			/* +1 leaves room for sprintf's trailing null */
  			t = (text *) palloc(len + 1);
  			SET_VARSIZE(t, len);
! 			sprintf(VARDATA(t), "%s='%s'", def->defname, value);
  
  			astate = accumArrayResult(astate, PointerGetDatum(t),
  									  false, TEXTOID,
***************
*** 982,990 **** parse_one_reloption(relopt_value *option, char *text_str, int text_len,
  				 errmsg("parameter \"%s\" specified more than once",
  						option->gen->name)));
  
! 	value_len = text_len - option->gen->namelen - 1;
  	value = (char *) palloc(value_len + 1);
! 	memcpy(value, text_str + option->gen->namelen + 1, value_len);
  	value[value_len] = '\0';
  
  	switch (option->gen->type)
--- 982,990 ----
  				 errmsg("parameter \"%s\" specified more than once",
  						option->gen->name)));
  
! 	value_len = text_len - option->gen->namelen - 3;
  	value = (char *) palloc(value_len + 1);
! 	memcpy(value, text_str + option->gen->namelen + 2, value_len);
  	value[value_len] = '\0';
  
  	switch (option->gen->type)
*** a/src/backend/catalog/information_schema.sql
--- b/src/backend/catalog/information_schema.sql
***************
*** 2502,2510 **** CREATE VIEW views AS
               AS character_data) AS view_definition,
  
             CAST(
!              CASE WHEN 'check_option=cascaded' = ANY (c.reloptions)
                    THEN 'CASCADED'
!                   WHEN 'check_option=local' = ANY (c.reloptions)
                    THEN 'LOCAL'
                    ELSE 'NONE' END
               AS character_data) AS check_option,
--- 2502,2510 ----
               AS character_data) AS view_definition,
  
             CAST(
!              CASE WHEN 'check_option=''cascaded''' = ANY (c.reloptions)
                    THEN 'CASCADED'
!                   WHEN 'check_option=''local''' = ANY (c.reloptions)
                    THEN 'LOCAL'
                    ELSE 'NONE' END
               AS character_data) AS check_option,
*** a/src/test/regress/expected/alter_table.out
--- b/src/test/regress/expected/alter_table.out
***************
*** 1823,1829 **** ERROR:  invalid value for integer option "autovacuum_analyze_threshold": 3min
   Column | Type | Modifiers | Storage  | Stats target | Description 
  --------+------+-----------+----------+--------------+-------------
   a      | text |           | extended |              | 
! Options: autovacuum_vacuum_cost_delay=80ms
  
  --
  -- lock levels
--- 1823,1829 ----
   Column | Type | Modifiers | Storage  | Stats target | Description 
  --------+------+-----------+----------+--------------+-------------
   a      | text |           | extended |              | 
! Options: autovacuum_vacuum_cost_delay='80ms'
  
  --
  -- lock levels
*** a/src/test/regress/expected/create_view.out
--- b/src/test/regress/expected/create_view.out
***************
*** 260,271 **** SELECT relname, relkind, reloptions FROM pg_class
         WHERE oid in ('mysecview1'::regclass, 'mysecview2'::regclass,
                       'mysecview3'::regclass, 'mysecview4'::regclass)
         ORDER BY relname;
!   relname   | relkind |        reloptions        
! ------------+---------+--------------------------
   mysecview1 | v       | 
!  mysecview2 | v       | {security_barrier=true}
!  mysecview3 | v       | {security_barrier=false}
!  mysecview4 | v       | {security_barrier=true}
  (4 rows)
  
  CREATE OR REPLACE VIEW mysecview1
--- 260,271 ----
         WHERE oid in ('mysecview1'::regclass, 'mysecview2'::regclass,
                       'mysecview3'::regclass, 'mysecview4'::regclass)
         ORDER BY relname;
!   relname   | relkind |         reloptions         
! ------------+---------+----------------------------
   mysecview1 | v       | 
!  mysecview2 | v       | {security_barrier='true'}
!  mysecview3 | v       | {security_barrier='false'}
!  mysecview4 | v       | {security_barrier='true'}
  (4 rows)
  
  CREATE OR REPLACE VIEW mysecview1
***************
*** 280,291 **** SELECT relname, relkind, reloptions FROM pg_class
         WHERE oid in ('mysecview1'::regclass, 'mysecview2'::regclass,
                       'mysecview3'::regclass, 'mysecview4'::regclass)
         ORDER BY relname;
!   relname   | relkind |        reloptions        
! ------------+---------+--------------------------
   mysecview1 | v       | 
   mysecview2 | v       | 
!  mysecview3 | v       | {security_barrier=true}
!  mysecview4 | v       | {security_barrier=false}
  (4 rows)
  
  -- Test view decompilation in the face of relation renaming conflicts
--- 280,291 ----
         WHERE oid in ('mysecview1'::regclass, 'mysecview2'::regclass,
                       'mysecview3'::regclass, 'mysecview4'::regclass)
         ORDER BY relname;
!   relname   | relkind |         reloptions         
! ------------+---------+----------------------------
   mysecview1 | v       | 
   mysecview2 | v       | 
!  mysecview3 | v       | {security_barrier='true'}
!  mysecview4 | v       | {security_barrier='false'}
  (4 rows)
  
  -- Test view decompilation in the face of relation renaming conflicts
*** a/src/test/regress/expected/updatable_views.out
--- b/src/test/regress/expected/updatable_views.out
***************
*** 1382,1388 **** View definition:
      base_tbl.b
     FROM base_tbl
    WHERE base_tbl.a < base_tbl.b;
! Options: check_option=local
  
  SELECT * FROM information_schema.views WHERE table_name = 'rw_view1';
   table_catalog | table_schema | table_name |          view_definition           | check_option | is_updatable | is_insertable_into | is_trigger_updatable | is_trigger_deletable | is_trigger_insertable_into 
--- 1382,1388 ----
      base_tbl.b
     FROM base_tbl
    WHERE base_tbl.a < base_tbl.b;
! Options: check_option='local'
  
  SELECT * FROM information_schema.views WHERE table_name = 'rw_view1';
   table_catalog | table_schema | table_name |          view_definition           | check_option | is_updatable | is_insertable_into | is_trigger_updatable | is_trigger_deletable | is_trigger_insertable_into 
***************
*** 1434,1440 **** View definition:
   SELECT rw_view1.a
     FROM rw_view1
    WHERE rw_view1.a < 10;
! Options: check_option=cascaded
  
  SELECT * FROM information_schema.views WHERE table_name = 'rw_view2';
   table_catalog | table_schema | table_name |      view_definition       | check_option | is_updatable | is_insertable_into | is_trigger_updatable | is_trigger_deletable | is_trigger_insertable_into 
--- 1434,1440 ----
   SELECT rw_view1.a
     FROM rw_view1
    WHERE rw_view1.a < 10;
! Options: check_option='cascaded'
  
  SELECT * FROM information_schema.views WHERE table_name = 'rw_view2';
   table_catalog | table_schema | table_name |      view_definition       | check_option | is_updatable | is_insertable_into | is_trigger_updatable | is_trigger_deletable | is_trigger_insertable_into 
***************
*** 1474,1480 **** View definition:
   SELECT rw_view1.a
     FROM rw_view1
    WHERE rw_view1.a < 10;
! Options: check_option=local
  
  SELECT * FROM information_schema.views WHERE table_name = 'rw_view2';
   table_catalog | table_schema | table_name |      view_definition       | check_option | is_updatable | is_insertable_into | is_trigger_updatable | is_trigger_deletable | is_trigger_insertable_into 
--- 1474,1480 ----
   SELECT rw_view1.a
     FROM rw_view1
    WHERE rw_view1.a < 10;
! Options: check_option='local'
  
  SELECT * FROM information_schema.views WHERE table_name = 'rw_view2';
   table_catalog | table_schema | table_name |      view_definition       | check_option | is_updatable | is_insertable_into | is_trigger_updatable | is_trigger_deletable | is_trigger_insertable_into 
*** a/src/test/regress/output/tablespace.source
--- b/src/test/regress/output/tablespace.source
***************
*** 4,12 **** ERROR:  unrecognized parameter "some_nonexistent_parameter"
  CREATE TABLESPACE testspacewith LOCATION '@testtablespace@' WITH (random_page_cost = 3.0); -- ok
  -- check to see the parameter was used
  SELECT spcoptions FROM pg_tablespace WHERE spcname = 'testspacewith';
!        spcoptions       
! ------------------------
!  {random_page_cost=3.0}
  (1 row)
  
  -- drop the tablespace so we can re-use the location
--- 4,12 ----
  CREATE TABLESPACE testspacewith LOCATION '@testtablespace@' WITH (random_page_cost = 3.0); -- ok
  -- check to see the parameter was used
  SELECT spcoptions FROM pg_tablespace WHERE spcname = 'testspacewith';
!         spcoptions        
! --------------------------
!  {random_page_cost='3.0'}
  (1 row)
  
  -- drop the tablespace so we can re-use the location
#6Tom Lane
tgl@sss.pgh.pa.us
In reply to: Michael Paquier (#5)
Re: [COMMITTERS] pgsql: Allow units to be specified in relation option setting value.

Michael Paquier <michael.paquier@gmail.com> writes:

The patch attached fixes pg_upgrade by putting quotes when generating
reloptions and it passes check-world. I imagine that having quotes by
default in the value of reloptions in pg_class is the price to pay for
supporting units. If this is not considered as a correct approach,
then reverting the patch would be wiser I guess.

Ugh. I'm not sure what the best solution is, but I don't think I like
that one.

Given that this patch broke both pg_dump and pg_upgrade, I think it should
be reverted for the time being, rather than applying a hasty hack.
Obviously more thought and testing is needed.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#7Andres Freund
andres@2ndquadrant.com
In reply to: Andres Freund (#2)
Re: pgsql: Allow units to be specified in relation option setting value.

On 2014-08-28 14:11:33 +0200, Andres Freund wrote:

Hi,

On 2014-08-28 07:15:35 +0000, Fujii Masao wrote:

Allow units to be specified in relation option setting value.

This introduces an infrastructure which allows us to specify the units
like ms (milliseconds) in integer relation option, like GUC parameter.
Currently only autovacuum_vacuum_cost_delay reloption can accept
the units.

This apparently broke pg_upgrade. I've not checked what's up there.

See
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&amp;dt=2014-08-28%2007%3A16%3A04
and many others.

The specific error is an unquoted 80ms in WITH
(autovacuum_vacuum_cost_delay=80ms);

Independent of that being fixable with some quoting or such, I'm a bit
doubtful about unconditionally adding the ms here. Won't that make it
unnecessarily hard to get 9.5 dumps into <9.5? I know that we don't make
any promises, but it mostly works nonetheless. And this doesn't seem
worth the breakage.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

#8Fujii Masao
masao.fujii@gmail.com
In reply to: Tom Lane (#6)
Re: pgsql: Allow units to be specified in relation option setting value.

On Thu, Aug 28, 2014 at 11:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Michael Paquier <michael.paquier@gmail.com> writes:

The patch attached fixes pg_upgrade by putting quotes when generating
reloptions and it passes check-world. I imagine that having quotes by
default in the value of reloptions in pg_class is the price to pay for
supporting units. If this is not considered as a correct approach,
then reverting the patch would be wiser I guess.

Ugh. I'm not sure what the best solution is, but I don't think I like
that one.

Another approach is to change pg_dump so that it encloses the relopt
values with single quotes. This is the same approach as what
pg_dumpall does for database or role-specific settings. Obvious
drawback of this approach is that it prevents pg_dump with 9.4 or
before from outputting the restorable dump. Maybe we can live with
this because there is no guarantee that older version of pg_dump can
work properly with newer major version of server. But maybe
someone cannot live with that. Not sure.

Further other approach is to change the reloptions code so that it
always stores the plain value without the units (i.e., 1000 is stored
if 1s is specified in autovacuum_vacuum_cost_delay)in pg_class.
This approach doesn't prevent older version of pg_dump from taking
the dump from v9.5 server. One drawback of this approach is that
reloption values are always stored without the units, which might
make it a bit hard for a user to see the reloption values from pg_class.

Regards,

--
Fujii Masao

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

#9Robert Haas
robertmhaas@gmail.com
In reply to: Fujii Masao (#8)
Re: pgsql: Allow units to be specified in relation option setting value.

On Thu, Aug 28, 2014 at 12:22 PM, Fujii Masao <masao.fujii@gmail.com> wrote:

On Thu, Aug 28, 2014 at 11:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Michael Paquier <michael.paquier@gmail.com> writes:

The patch attached fixes pg_upgrade by putting quotes when generating
reloptions and it passes check-world. I imagine that having quotes by
default in the value of reloptions in pg_class is the price to pay for
supporting units. If this is not considered as a correct approach,
then reverting the patch would be wiser I guess.

Ugh. I'm not sure what the best solution is, but I don't think I like
that one.

Another approach is to change pg_dump so that it encloses the relopt
values with single quotes. This is the same approach as what
pg_dumpall does for database or role-specific settings. Obvious
drawback of this approach is that it prevents pg_dump with 9.4 or
before from outputting the restorable dump. Maybe we can live with
this because there is no guarantee that older version of pg_dump can
work properly with newer major version of server. But maybe
someone cannot live with that. Not sure.

To me, this doesn't seem nearly important enough to justify breaking
pg_dump compatibility. AAUI, this is just a cosmetic improvement, so
we shouldn't break functional things for that.

Further other approach is to change the reloptions code so that it
always stores the plain value without the units (i.e., 1000 is stored
if 1s is specified in autovacuum_vacuum_cost_delay)in pg_class.
This approach doesn't prevent older version of pg_dump from taking
the dump from v9.5 server. One drawback of this approach is that
reloption values are always stored without the units, which might
make it a bit hard for a user to see the reloption values from pg_class.

This seems like the way to go.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

#10Tom Lane
tgl@sss.pgh.pa.us
In reply to: Robert Haas (#9)
Re: pgsql: Allow units to be specified in relation option setting value.

Robert Haas <robertmhaas@gmail.com> writes:

On Thu, Aug 28, 2014 at 12:22 PM, Fujii Masao <masao.fujii@gmail.com> wrote:

Another approach is to change pg_dump so that it encloses the relopt
values with single quotes. This is the same approach as what
pg_dumpall does for database or role-specific settings.

To me, this doesn't seem nearly important enough to justify breaking
pg_dump compatibility. AAUI, this is just a cosmetic improvement, so
we shouldn't break functional things for that.

Indeed. I am not convinced that pg_dump is the only client-side code
that would get broken, either.

Further other approach is to change the reloptions code so that it
always stores the plain value without the units (i.e., 1000 is stored
if 1s is specified in autovacuum_vacuum_cost_delay)in pg_class.

This seems like the way to go.

Yeah, it's the best idea I can think of either. It's a tad annoying but
I think we don't want to take the compatibility risks of storing
unit-ified values in reloptions.

In the meantime, the buildfarm is still all red. Can we please revert
this patch until a fixed version is ready?

regards, tom lane

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

#11Fujii Masao
masao.fujii@gmail.com
In reply to: Tom Lane (#10)
Re: pgsql: Allow units to be specified in relation option setting value.

On Fri, Aug 29, 2014 at 4:34 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.com> writes:

On Thu, Aug 28, 2014 at 12:22 PM, Fujii Masao <masao.fujii@gmail.com> wrote:

Another approach is to change pg_dump so that it encloses the relopt
values with single quotes. This is the same approach as what
pg_dumpall does for database or role-specific settings.

To me, this doesn't seem nearly important enough to justify breaking
pg_dump compatibility. AAUI, this is just a cosmetic improvement, so
we shouldn't break functional things for that.

Indeed. I am not convinced that pg_dump is the only client-side code
that would get broken, either.

Further other approach is to change the reloptions code so that it
always stores the plain value without the units (i.e., 1000 is stored
if 1s is specified in autovacuum_vacuum_cost_delay)in pg_class.

This seems like the way to go.

Agreed.

Yeah, it's the best idea I can think of either. It's a tad annoying but
I think we don't want to take the compatibility risks of storing
unit-ified values in reloptions.

In the meantime, the buildfarm is still all red. Can we please revert
this patch until a fixed version is ready?

OK, reverted.

Regards,

--
Fujii Masao

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

#12Michael Paquier
michael.paquier@gmail.com
In reply to: Fujii Masao (#11)
Re: pgsql: Allow units to be specified in relation option setting value.

On Thu, Aug 28, 2014 at 3:27 PM, Fujii Masao <masao.fujii@gmail.com> wrote:

OK, reverted.

As this patch needs more care in the way it is stored in pg_class as
reloptions (need more logic to parse correctly units from the actual
values that are store), I just marked it as returned with feedback.
--
Michael

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers