Re: allowed user/db variables

Lists: pgsql-hackerspgsql-patches
From: Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>
To: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: allowed user/db variables
Date: 2003-06-18 21:29:57
Message-ID: 3EF0D9D5.8090906@web.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

I wonder if there's a way to read all allowed user/database variables
that can be set/reset.
I'd like to have this self-configured in pgAdmin3 instead of hard-coded.

Can you give a hint?

Regards,
Andreas


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allowed user/db variables
Date: 2003-06-18 22:11:40
Message-ID: 4702.1055974300@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de> writes:
> I wonder if there's a way to read all allowed user/database variables
> that can be set/reset.
> I'd like to have this self-configured in pgAdmin3 instead of hard-coded.

Look at SHOW ALL, maybe? Or the pg_settings system view?

If you're willing to think about a solution that would only exist
starting in 7.4 --- some of my cohorts at Red Hat are about to submit
patches that create a separate "pg_guc" executable that contains
another copy of the backend's GUC variable table, and can be used to
obtain the set of known variables, their wired-in default values, min
and max values, etc. So you could imagine executing this program to
get the info. However, this would only work on the machine where the
stuff is installed, not necessarily on a remote client, so maybe it
wouldn't help pgAdmin.

If anyone's wondering why the RH guys want such an executable instead
of adding functionality to SHOW, it's because they want to be able to
get the info even when the postmaster isn't running; it's for a tool
that will help people set up postgresql.conf, so it seems essential that
the knowledge be available before starting the postmaster.

It occurs to me that we could consider adding columns to pg_settings
to make more info available to remote clients, too. The current value
of a setting is far from its only interesting property ...

regards, tom lane


From: Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allowed user/db variables
Date: 2003-06-18 22:19:54
Message-ID: 3EF0E58A.5030304@web.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:

>Look at SHOW ALL, maybe?
>
Of course.... Sorry.

>If you're willing to think about a solution that would only exist
>starting in 7.4 --- some of my cohorts at Red Hat are about to submit
>patches that create a separate "pg_guc" executable that contains
>another copy of the backend's GUC variable table, and can be used to
>obtain the set of known variables, their wired-in default values, min
>and max values, etc. So you could imagine executing this program to
>get the info. However, this would only work on the machine where the
>stuff is installed, not necessarily on a remote client, so maybe it
>wouldn't help pgAdmin.
>
No, need to retrieve this online.
Thanks,
Andreas


From: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
To: "Andreas Pflug" <Andreas(dot)Pflug(at)web(dot)de>, "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allowed user/db variables
Date: 2003-06-19 01:28:26
Message-ID: 026e01c33602$153623d0$6500a8c0@fhp.internal
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

> I wonder if there's a way to read all allowed user/database variables
> that can be set/reset.
> I'd like to have this self-configured in pgAdmin3 instead of hard-coded.

You know, I was just about to ask this for phpPgAdmin3!!!

SHOW ALL;

Will help, but won't tell the whole story...

Chris


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
Cc: "Andreas Pflug" <Andreas(dot)Pflug(at)web(dot)de>, "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allowed user/db variables
Date: 2003-06-19 03:09:46
Message-ID: 5998.1055992186@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
> SHOW ALL;
> Will help, but won't tell the whole story...

See my followup. Which bits of info would you like to see added that
SHOW doesn't reveal?

regards, tom lane


From: Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allowed user/db variables
Date: 2003-06-19 08:49:39
Message-ID: 3EF17923.5010402@web.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:

>"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
>
>
>>SHOW ALL;
>>Will help, but won't tell the whole story...
>>
>>
>
>See my followup. Which bits of info would you like to see added that
>SHOW doesn't reveal?
>
>
>
I'd like to have type (bool/numeric/alpha/value list), min, max and
values in pg_settings.
Currently, you can select the name from a combobox, but type any value
you like, waiting for the backend to complain (or accept).

Regards,
Andreas


From: Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allowed user/db variables
Date: 2003-06-19 10:32:07
Message-ID: 3EF19127.1050906@web.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

Andreas Pflug wrote:

> I'd like to have type (bool/numeric/alpha/value list), min, max and
> values in pg_settings.
> Currently, you can select the name from a combobox, but type any value
> you like, waiting for the backend to complain (or accept).
>
Additionally, it should be marked which vars are legal to set online.
Currently, "port" and "ssl" are offered to change too...

Regards,
Andreas


From: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Andreas Pflug" <Andreas(dot)Pflug(at)web(dot)de>, "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allowed user/db variables
Date: 2003-06-20 01:21:52
Message-ID: 003401c336ca$548e2000$2800a8c0@mars
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

> See my followup. Which bits of info would you like to see added that
> SHOW doesn't reveal?

Unlike andreas, I'm not interested in the types and ranges of values, what I
need to know is the GUC variables that the user is allowed to set, in
particular what they can ALTER USER / SET ... so that I can display that
feature...

Chris


From: Joe Conway <mail(at)joeconway(dot)com>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allowed user/db variables
Date: 2003-06-25 06:45:28
Message-ID: 3EF94508.6010300@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

Christopher Kings-Lynne wrote:
>>See my followup. Which bits of info would you like to see added that
>>SHOW doesn't reveal?
>
> Unlike andreas, I'm not interested in the types and ranges of values, what I
> need to know is the GUC variables that the user is allowed to set, in
> particular what they can ALTER USER / SET ... so that I can display that
> feature...
>

I was considering adding this and the stuff Andreas requested to
pg_settings (but not "SHOW ALL" or "SHOW x" unless people feel it's
important to kept them consistent with pg_settings). Were the Red Hat
guys going to do this?

Joe


From: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
To: "Joe Conway" <mail(at)joeconway(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Andreas Pflug" <Andreas(dot)Pflug(at)web(dot)de>, "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allowed user/db variables
Date: 2003-06-25 06:56:18
Message-ID: 0dca01c33ae6$e09e5db0$2800a8c0@mars
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

> I was considering adding this and the stuff Andreas requested to
> pg_settings (but not "SHOW ALL" or "SHOW x" unless people feel it's
> important to kept them consistent with pg_settings). Were the Red Hat
> guys going to do this?

pg_settings would be fine for phpPgAdmin.

Chris


From: Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allowed user/db variables
Date: 2003-06-25 12:24:49
Message-ID: 3EF99491.5020803@web.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

Christopher Kings-Lynne wrote:

>>I was considering adding this and the stuff Andreas requested to
>>pg_settings (but not "SHOW ALL" or "SHOW x" unless people feel it's
>>important to kept them consistent with pg_settings). Were the Red Hat
>>guys going to do this?
>>
>>
>
>pg_settings would be fine for phpPgAdmin.
>
>
Same for pgAdmin3.

Regards,
Andreas


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Joe Conway <mail(at)joeconway(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allowed user/db variables
Date: 2003-06-25 13:53:35
Message-ID: 25036.1056549215@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

>>> I was considering adding this and the stuff Andreas requested to
>>> pg_settings (but not "SHOW ALL" or "SHOW x" unless people feel it's
>>> important to kept them consistent with pg_settings). Were the Red Hat
>>> guys going to do this?
>>
>> pg_settings would be fine for phpPgAdmin.
>>
> Same for pgAdmin3.

I agree with this plan also. I'm not sure if the RH guys had intended
to get around to this or not --- it's not on their shortlist of stuff
they need for their tools.

The proposed patch from RH includes addition of descriptions to the
variables' table entries in guc.c. It might make sense to include these
as a column in pg_settings as well; but if we do then changing the view
would have to wait till that patch is submitted and accepted. (I was
offline yesterday but it doesn't look like anything's been done; I will
remind 'em that feature freeze is hard upon us.)

regards, tom lane


From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] allowed user/db variables
Date: 2003-06-25 23:30:17
Message-ID: 3EFA3089.9020801@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

(moved to PATCHES)

Tom Lane wrote:
> I agree with this plan also. I'm not sure if the RH guys had intended
> to get around to this or not --- it's not on their shortlist of stuff
> they need for their tools.
>
> The proposed patch from RH includes addition of descriptions to the
> variables' table entries in guc.c. It might make sense to include these
> as a column in pg_settings as well; but if we do then changing the view
> would have to wait till that patch is submitted and accepted. (I was
> offline yesterday but it doesn't look like anything's been done; I will
> remind 'em that feature freeze is hard upon us.)

Here is a patch to expand pg_settings. I included more than discussed
because it was easy and I thought it might be useful. Let me know if you
want some of them removed.

Passes all regression tests.

I'll send in a documentation patch once I'm sure what new columns we are
actually going to add (i.e. this patch, descriptions, or some
combination thereof).

If there are no objections, please apply.

Joe

p.s. here is some sample (expanded) output:

regression=# select * from pg_settings;
-[ RECORD 1 ]----+--------------------------------------
name | add_missing_from
setting | on
context | user
vartype | bool
reset_source | default
session_source | default
tentative_source | default
source | default
boot_val |
reset_val | on
session_val | on
tentative_val | off
min_val |
max_val |

[ ... ]

-[ RECORD 14 ]---+--------------------------------------
name | DateStyle
setting | ISO with US (NonEuropean) conventions
context | user
vartype | string
reset_source | default
session_source | default
tentative_source | default
source | default
boot_val | ISO, US
reset_val | ISO, US
session_val | ISO, US
tentative_val |
min_val |
max_val |
-[ RECORD 15 ]---+--------------------------------------
name | db_user_namespace
setting | off
context | sighup
vartype | bool
reset_source | default
session_source | default
tentative_source | default
source | default
boot_val |
reset_val | off
session_val | off
tentative_val | off
min_val |
max_val |

[ ... ]

-[ RECORD 26 ]---+--------------------------------------
name | effective_cache_size
setting | 1000
context | user
vartype | real
reset_source | default
session_source | default
tentative_source | default
source | default
boot_val |
reset_val | 1000
session_val | 1000
tentative_val | 0
min_val | 0
max_val | 1.79769e+308

[ ... ]

-[ RECORD 55 ]---+--------------------------------------
name | log_duration
setting | off
context | super-user
vartype | bool
reset_source | default
session_source | default
tentative_source | default
source | default
boot_val |
reset_val | off
session_val | off
tentative_val | off
min_val |
max_val |

[ ... ]

-[ RECORD 83 ]---+--------------------------------------
name | shared_buffers
setting | 64
context | postmaster
vartype | integer
reset_source | default
session_source | default
tentative_source | default
source | default
boot_val |
reset_val | 64
session_val | 64
tentative_val | 0
min_val | 16
max_val | 2147483647

Attachment Content-Type Size
pg_settings_expanded.1.patch text/plain 20.5 KB

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] allowed user/db variables
Date: 2003-06-25 23:52:56
Message-ID: 19475.1056585176@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

Joe Conway <mail(at)joeconway(dot)com> writes:
> Here is a patch to expand pg_settings. I included more than discussed
> because it was easy and I thought it might be useful. Let me know if you
> want some of them removed.

Much of what you've included is part of the internal implementation of
GUC, and I think it's unwise to expose it; any future changes in GUC
might break the view (or more accurately break apps that are expecting
the view to look a particular way).

I agree with adding context, vartype, min_val, and max_val. Not sure
about boot_val or reset_val. The RH guys do want to expose boot_val
in their tool, since it's concerned with helping people set up
postgresql.conf, but is it really useful for clients to see it?
reset_val might be okay to expose ... not sure if we'd ever want to
remove that concept from the implementation.

> name | DateStyle
> setting | ISO with US (NonEuropean) conventions

This reminds me, someone (Barry?) was griping that SHOW DATESTYLE
doesn't produce a value that SET DATESTYLE will take. Did we agree
that it was OK to change the output to look like "ISO, US" etc?

regards, tom lane


From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] allowed user/db variables
Date: 2003-06-26 01:09:42
Message-ID: 3EFA47D6.5080509@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>>Here is a patch to expand pg_settings. I included more than discussed
>>because it was easy and I thought it might be useful. Let me know if you
>>want some of them removed.
>
> Much of what you've included is part of the internal implementation of
> GUC, and I think it's unwise to expose it; any future changes in GUC
> might break the view (or more accurately break apps that are expecting
> the view to look a particular way).
>
> I agree with adding context, vartype, min_val, and max_val. Not sure
> about boot_val or reset_val. The RH guys do want to expose boot_val
> in their tool, since it's concerned with helping people set up
> postgresql.conf, but is it really useful for clients to see it?
> reset_val might be okay to expose ... not sure if we'd ever want to
> remove that concept from the implementation.

I thought you might say that. What about this list:

name
setting
context
vartype
source
min_val
max_val

ISTM that "source" is worth knowing.

>>name | DateStyle
>>setting | ISO with US (NonEuropean) conventions
>
> This reminds me, someone (Barry?) was griping that SHOW DATESTYLE
> doesn't produce a value that SET DATESTYLE will take. Did we agree
> that it was OK to change the output to look like "ISO, US" etc?

I vaguely remember the thread:
http://archives.postgresql.org/pgsql-hackers/2003-05/msg00190.php

I don't see any followup (agreements or disagreements). Do you want me
to change that while I'm at it?

Joe


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] allowed user/db variables
Date: 2003-06-26 02:37:48
Message-ID: 20518.1056595068@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

Joe Conway <mail(at)joeconway(dot)com> writes:
> ISTM that "source" is worth knowing.

Hm, possibly. Any other opinions?

>> This reminds me, someone (Barry?) was griping that SHOW DATESTYLE
>> doesn't produce a value that SET DATESTYLE will take. Did we agree
>> that it was OK to change the output to look like "ISO, US" etc?

> I vaguely remember the thread:
> http://archives.postgresql.org/pgsql-hackers/2003-05/msg00190.php

> I don't see any followup (agreements or disagreements). Do you want me
> to change that while I'm at it?

No, I can handle it (and it should be a separate commit anyway).

regards, tom lane


From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] allowed user/db variables
Date: 2003-06-26 05:13:16
Message-ID: 3EFA80EC.7020608@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>>ISTM that "source" is worth knowing.
>
> Hm, possibly. Any other opinions?

This version has the seven fields I proposed, including "source". Here's
an example that shows why I think it's valuable:

regression=# \x
Expanded display is on.
regression=# select * from pg_settings where name = 'enable_seqscan';
-[ RECORD 1 ]-----------
name | enable_seqscan
setting | on
context | user
vartype | bool
source | default
min_val |
max_val |

regression=# update pg_settings set setting = 'off' where name =
'enable_seqscan';
-[ RECORD 1 ]---
set_config | off

regression=# select * from pg_settings where name = 'enable_seqscan';
-[ RECORD 1 ]-----------
name | enable_seqscan
setting | off
context | user
vartype | bool
source | session
min_val |
max_val |

regression=# alter user postgres set enable_seqscan to 'off';
ALTER USER

(log out and then back in again)

regression=# \x
Expanded display is on.
regression=# select * from pg_settings where name = 'enable_seqscan';
-[ RECORD 1 ]-----------
name | enable_seqscan
setting | off
context | user
vartype | bool
source | user
min_val |
max_val |

In the first case, enable_seqscan is set to its default value. After
setting it to off, it is obvious that the value has been changed for the
session only. In the third case, you can see that the value has been set
specifically for the user.

This version of the patch also includes documentation changes. Passes
all regression tests. Please apply.

Joe

Attachment Content-Type Size
pg_settings_expanded.2.patch text/plain 19.7 KB

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Subject: Re: [HACKERS] allowed user/db variables
Date: 2003-07-19 04:23:46
Message-ID: 3F18C7D2.10509@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

I'm going to resend the patches that I have outstanding since it appears
some may have been lost. Here's the third of three.
===================================================

Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>>ISTM that "source" is worth knowing.
>
> Hm, possibly. Any other opinions?

This version has the seven fields I proposed, including "source". Here's
an example that shows why I think it's valuable:

regression=# \x
Expanded display is on.
regression=# select * from pg_settings where name = 'enable_seqscan';
-[ RECORD 1 ]-----------
name | enable_seqscan
setting | on
context | user
vartype | bool
source | default
min_val |
max_val |

regression=# update pg_settings set setting = 'off' where name =
'enable_seqscan';
-[ RECORD 1 ]---
set_config | off

regression=# select * from pg_settings where name = 'enable_seqscan';
-[ RECORD 1 ]-----------
name | enable_seqscan
setting | off
context | user
vartype | bool
source | session
min_val |
max_val |

regression=# alter user postgres set enable_seqscan to 'off';
ALTER USER

(log out and then back in again)

regression=# \x
Expanded display is on.
regression=# select * from pg_settings where name = 'enable_seqscan';
-[ RECORD 1 ]-----------
name | enable_seqscan
setting | off
context | user
vartype | bool
source | user
min_val |
max_val |

In the first case, enable_seqscan is set to its default value. After
setting it to off, it is obvious that the value has been changed for the
session only. In the third case, you can see that the value has been set
specifically for the user.

This version of the patch also includes documentation changes. Passes
all regression tests. Please apply.

Joe

Attachment Content-Type Size
pg_settings_expanded.2.patch text/plain 19.7 KB

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] allowed user/db variables
Date: 2003-07-20 00:48:06
Message-ID: 200307200048.h6K0m6w00321@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches


Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------

Joe Conway wrote:
> I'm going to resend the patches that I have outstanding since it appears
> some may have been lost. Here's the third of three.
> ===================================================
>
>
> Tom Lane wrote:
> > Joe Conway <mail(at)joeconway(dot)com> writes:
> >>ISTM that "source" is worth knowing.
> >
> > Hm, possibly. Any other opinions?
>
> This version has the seven fields I proposed, including "source". Here's
> an example that shows why I think it's valuable:
>
> regression=# \x
> Expanded display is on.
> regression=# select * from pg_settings where name = 'enable_seqscan';
> -[ RECORD 1 ]-----------
> name | enable_seqscan
> setting | on
> context | user
> vartype | bool
> source | default
> min_val |
> max_val |
>
> regression=# update pg_settings set setting = 'off' where name =
> 'enable_seqscan';
> -[ RECORD 1 ]---
> set_config | off
>
> regression=# select * from pg_settings where name = 'enable_seqscan';
> -[ RECORD 1 ]-----------
> name | enable_seqscan
> setting | off
> context | user
> vartype | bool
> source | session
> min_val |
> max_val |
>
> regression=# alter user postgres set enable_seqscan to 'off';
> ALTER USER
>
> (log out and then back in again)
>
> regression=# \x
> Expanded display is on.
> regression=# select * from pg_settings where name = 'enable_seqscan';
> -[ RECORD 1 ]-----------
> name | enable_seqscan
> setting | off
> context | user
> vartype | bool
> source | user
> min_val |
> max_val |
>
> In the first case, enable_seqscan is set to its default value. After
> setting it to off, it is obvious that the value has been changed for the
> session only. In the third case, you can see that the value has been set
> specifically for the user.
>
> This version of the patch also includes documentation changes. Passes
> all regression tests. Please apply.
>
> Joe
>

> Index: doc/src/sgml/runtime.sgml
> ===================================================================
> RCS file: /opt/src/cvs/pgsql-server/doc/src/sgml/runtime.sgml,v
> retrieving revision 1.187
> diff -c -r1.187 runtime.sgml
> *** doc/src/sgml/runtime.sgml 25 Jun 2003 01:13:24 -0000 1.187
> --- doc/src/sgml/runtime.sgml 26 Jun 2003 05:01:56 -0000
> ***************
> *** 571,584 ****
> <row>
> <entry><literal>name</literal></entry>
> <entry><type>text</type></entry>
> ! <entry>The name of the run-time configuration parameter</entry>
> </row>
>
> <row>
> <entry><literal>setting</literal></entry>
> <entry><type>text</type></entry>
> ! <entry>The current value of the run-time configuration parameter</entry>
> </row>
> </tbody>
> </tgroup>
> </table>
> --- 571,615 ----
> <row>
> <entry><literal>name</literal></entry>
> <entry><type>text</type></entry>
> ! <entry>run-time configuration parameter name</entry>
> </row>
>
> <row>
> <entry><literal>setting</literal></entry>
> <entry><type>text</type></entry>
> ! <entry>current value of the parameter</entry>
> </row>
> +
> + <row>
> + <entry><literal>context</literal></entry>
> + <entry><type>text</type></entry>
> + <entry>context required to set the parameter's value</entry>
> + </row>
> +
> + <row>
> + <entry><literal>vartype</literal></entry>
> + <entry><type>text</type></entry>
> + <entry>parameter type</entry>
> + </row>
> +
> + <row>
> + <entry><literal>source</literal></entry>
> + <entry><type>text</type></entry>
> + <entry>source of the current parameter value</entry>
> + </row>
> +
> + <row>
> + <entry><literal>min_val</literal></entry>
> + <entry><type>text</type></entry>
> + <entry>minimum allowed value of the parameter</entry>
> + </row>
> +
> + <row>
> + <entry><literal>max_val</literal></entry>
> + <entry><type>text</type></entry>
> + <entry>maximum allowed value of the parameter</entry>
> + </row>
> +
> </tbody>
> </tgroup>
> </table>
> Index: src/backend/utils/misc/guc.c
> ===================================================================
> RCS file: /opt/src/cvs/pgsql-server/src/backend/utils/misc/guc.c,v
> retrieving revision 1.131
> diff -c -r1.131 guc.c
> *** src/backend/utils/misc/guc.c 11 Jun 2003 22:13:22 -0000 1.131
> --- src/backend/utils/misc/guc.c 26 Jun 2003 04:03:00 -0000
> ***************
> *** 159,168 ****
> */
> enum config_type
> {
> ! PGC_BOOL,
> ! PGC_INT,
> ! PGC_REAL,
> ! PGC_STRING
> };
>
> /* Generic fields applicable to all types of variables */
> --- 159,208 ----
> */
> enum config_type
> {
> ! PGC_BOOL = 0,
> ! PGC_INT = 1,
> ! PGC_REAL = 2,
> ! PGC_STRING = 3
> ! };
> !
> ! /*
> ! * Used for pg_settings. Keep in sync with config_type enum above
> ! */
> ! static char *config_type_name[] =
> ! {
> ! "bool",
> ! "integer",
> ! "real",
> ! "string"
> ! };
> !
> ! /*
> ! * Used for pg_settings. Keep in sync with GucContext enum in guc.h
> ! */
> ! static char *GucContextName[] =
> ! {
> ! "internal",
> ! "postmaster",
> ! "sighup",
> ! "backend",
> ! "super-user",
> ! "user"
> ! };
> !
> ! /*
> ! * Used for pg_settings. Keep in sync with GucSource enum in guc.h
> ! */
> ! static char *GucSourceName[] =
> ! {
> ! "default",
> ! "environment variable",
> ! "configuration file",
> ! "command line",
> ! "database",
> ! "user",
> ! "client",
> ! "override",
> ! "session"
> };
>
> /* Generic fields applicable to all types of variables */
> ***************
> *** 2617,2639 ****
> * Return GUC variable value by variable number; optionally return canonical
> * form of name. Return value is palloc'd.
> */
> ! char *
> ! GetConfigOptionByNum(int varnum, const char **varname, bool *noshow)
> {
> ! struct config_generic *conf;
>
> /* check requested variable number valid */
> Assert((varnum >= 0) && (varnum < num_guc_variables));
>
> conf = guc_variables[varnum];
>
> - if (varname)
> - *varname = conf->name;
> -
> if (noshow)
> *noshow = (conf->flags & GUC_NO_SHOW_ALL) ? true : false;
>
> ! return _ShowOption(conf);
> }
>
> /*
> --- 2657,2758 ----
> * Return GUC variable value by variable number; optionally return canonical
> * form of name. Return value is palloc'd.
> */
> ! void
> ! GetConfigOptionByNum(int varnum, const char **values, bool *noshow)
> {
> ! char buffer[256];
> ! struct config_generic *conf;
>
> /* check requested variable number valid */
> Assert((varnum >= 0) && (varnum < num_guc_variables));
>
> conf = guc_variables[varnum];
>
> if (noshow)
> *noshow = (conf->flags & GUC_NO_SHOW_ALL) ? true : false;
>
> ! /* first get the generic attributes */
> !
> ! /* name */
> ! values[0] = conf->name;
> !
> ! /* setting : use _ShowOption in order to avoid duplicating the logic */
> ! values[1] = _ShowOption(conf);
> !
> ! /* context */
> ! values[2] = GucContextName[conf->context];
> !
> ! /* vartype */
> ! values[3] = config_type_name[conf->vartype];
> !
> ! /* source */
> ! values[4] = GucSourceName[conf->source];
> !
> ! /* now get the type specifc attributes */
> ! switch (conf->vartype)
> ! {
> ! case PGC_BOOL:
> ! {
> ! /* min_val */
> ! values[5] = NULL;
> !
> ! /* max_val */
> ! values[6] = NULL;
> ! }
> ! break;
> !
> ! case PGC_INT:
> ! {
> ! struct config_int *lconf = (struct config_int *) conf;
> !
> ! /* min_val */
> ! snprintf(buffer, sizeof(buffer), "%d", lconf->min);
> ! values[5] = pstrdup(buffer);
> !
> ! /* max_val */
> ! snprintf(buffer, sizeof(buffer), "%d", lconf->max);
> ! values[6] = pstrdup(buffer);
> ! }
> ! break;
> !
> ! case PGC_REAL:
> ! {
> ! struct config_real *lconf = (struct config_real *) conf;
> !
> ! /* min_val */
> ! snprintf(buffer, sizeof(buffer), "%g", lconf->min);
> ! values[5] = pstrdup(buffer);
> !
> ! /* max_val */
> ! snprintf(buffer, sizeof(buffer), "%g", lconf->max);
> ! values[6] = pstrdup(buffer);
> ! }
> ! break;
> !
> ! case PGC_STRING:
> ! {
> ! /* min_val */
> ! values[5] = NULL;
> !
> ! /* max_val */
> ! values[6] = NULL;
> ! }
> ! break;
> !
> ! default:
> ! {
> ! /*
> ! * should never get here, but in case we do, set 'em to NULL
> ! */
> !
> ! /* min_val */
> ! values[5] = NULL;
> !
> ! /* max_val */
> ! values[6] = NULL;
> ! }
> ! break;
> ! }
> }
>
> /*
> ***************
> *** 2673,2678 ****
> --- 2792,2799 ----
> * show_all_settings - equiv to SHOW ALL command but implemented as
> * a Table Function.
> */
> + #define NUM_PG_SETTINGS_ATTS 7
> +
> Datum
> show_all_settings(PG_FUNCTION_ARGS)
> {
> ***************
> *** 2696,2707 ****
> */
> oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
>
> ! /* need a tuple descriptor representing two TEXT columns */
> ! tupdesc = CreateTemplateTupleDesc(2, false);
> TupleDescInitEntry(tupdesc, (AttrNumber) 1, "name",
> TEXTOID, -1, 0, false);
> TupleDescInitEntry(tupdesc, (AttrNumber) 2, "setting",
> TEXTOID, -1, 0, false);
>
> /* allocate a slot for a tuple with this tupdesc */
> slot = TupleDescGetSlot(tupdesc);
> --- 2817,2841 ----
> */
> oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
>
> ! /*
> ! * need a tuple descriptor representing NUM_PG_SETTINGS_ATTS columns
> ! * of the appropriate types
> ! */
> ! tupdesc = CreateTemplateTupleDesc(NUM_PG_SETTINGS_ATTS, false);
> TupleDescInitEntry(tupdesc, (AttrNumber) 1, "name",
> TEXTOID, -1, 0, false);
> TupleDescInitEntry(tupdesc, (AttrNumber) 2, "setting",
> TEXTOID, -1, 0, false);
> + TupleDescInitEntry(tupdesc, (AttrNumber) 3, "context",
> + TEXTOID, -1, 0, false);
> + TupleDescInitEntry(tupdesc, (AttrNumber) 4, "vartype",
> + TEXTOID, -1, 0, false);
> + TupleDescInitEntry(tupdesc, (AttrNumber) 5, "source",
> + TEXTOID, -1, 0, false);
> + TupleDescInitEntry(tupdesc, (AttrNumber) 6, "min_val",
> + TEXTOID, -1, 0, false);
> + TupleDescInitEntry(tupdesc, (AttrNumber) 7, "max_val",
> + TEXTOID, -1, 0, false);
>
> /* allocate a slot for a tuple with this tupdesc */
> slot = TupleDescGetSlot(tupdesc);
> ***************
> *** 2732,2740 ****
>
> if (call_cntr < max_calls) /* do when there is more left to send */
> {
> ! char *values[2];
> ! char *varname;
> ! char *varval;
> bool noshow;
> HeapTuple tuple;
> Datum result;
> --- 2866,2872 ----
>
> if (call_cntr < max_calls) /* do when there is more left to send */
> {
> ! char *values[NUM_PG_SETTINGS_ATTS];
> bool noshow;
> HeapTuple tuple;
> Datum result;
> ***************
> *** 2744,2758 ****
> */
> do
> {
> ! varval = GetConfigOptionByNum(call_cntr,
> ! (const char **) &varname,
> ! &noshow);
> if (noshow)
> {
> - /* varval is a palloc'd copy, so free it */
> - if (varval != NULL)
> - pfree(varval);
> -
> /* bump the counter and get the next config setting */
> call_cntr = ++funcctx->call_cntr;
>
> --- 2876,2884 ----
> */
> do
> {
> ! GetConfigOptionByNum(call_cntr, (const char **) values, &noshow);
> if (noshow)
> {
> /* bump the counter and get the next config setting */
> call_cntr = ++funcctx->call_cntr;
>
> ***************
> *** 2762,2784 ****
> }
> } while (noshow);
>
> - /*
> - * Prepare a values array for storage in our slot. This should be
> - * an array of C strings which will be processed later by the
> - * appropriate "in" functions.
> - */
> - values[0] = varname;
> - values[1] = varval;
> -
> /* build a tuple */
> tuple = BuildTupleFromCStrings(attinmeta, values);
>
> /* make the tuple into a datum */
> result = TupleGetDatum(slot, tuple);
> -
> - /* Clean up */
> - if (varval != NULL)
> - pfree(varval);
>
> SRF_RETURN_NEXT(funcctx, result);
> }
> --- 2888,2898 ----
> Index: src/bin/initdb/initdb.sh
> ===================================================================
> RCS file: /opt/src/cvs/pgsql-server/src/bin/initdb/initdb.sh,v
> retrieving revision 1.192
> diff -c -r1.192 initdb.sh
> *** src/bin/initdb/initdb.sh 2 Jun 2003 19:00:29 -0000 1.192
> --- src/bin/initdb/initdb.sh 26 Jun 2003 03:56:23 -0000
> ***************
> *** 971,977 ****
>
> CREATE VIEW pg_settings AS \
> SELECT * \
> ! FROM pg_show_all_settings() AS A(name text, setting text);
>
> CREATE RULE pg_settings_u AS \
> ON UPDATE TO pg_settings \
> --- 971,979 ----
>
> CREATE VIEW pg_settings AS \
> SELECT * \
> ! FROM pg_show_all_settings() AS A \
> ! (name text, setting text, context text, vartype text, \
> ! source text, min_val text, max_val text);
>
> CREATE RULE pg_settings_u AS \
> ON UPDATE TO pg_settings \
> Index: src/include/utils/guc.h
> ===================================================================
> RCS file: /opt/src/cvs/pgsql-server/src/include/utils/guc.h,v
> retrieving revision 1.32
> diff -c -r1.32 guc.h
> *** src/include/utils/guc.h 11 Jun 2003 18:01:14 -0000 1.32
> --- src/include/utils/guc.h 26 Jun 2003 02:58:54 -0000
> ***************
> *** 49,63 ****
> * we don't yet know if the user is a superuser.
> *
> * USERSET options can be set by anyone any time.
> */
> typedef enum
> {
> ! PGC_INTERNAL,
> ! PGC_POSTMASTER,
> ! PGC_SIGHUP,
> ! PGC_BACKEND,
> ! PGC_SUSET,
> ! PGC_USERSET
> } GucContext;
>
> /*
> --- 49,65 ----
> * we don't yet know if the user is a superuser.
> *
> * USERSET options can be set by anyone any time.
> + *
> + * Keep in sync with GucContextName in guc.c
> */
> typedef enum
> {
> ! PGC_INTERNAL = 0,
> ! PGC_POSTMASTER = 1,
> ! PGC_SIGHUP = 2,
> ! PGC_BACKEND = 3,
> ! PGC_SUSET = 4,
> ! PGC_USERSET = 5
> } GucContext;
>
> /*
> ***************
> *** 69,74 ****
> --- 71,78 ----
> * Sources <= PGC_S_OVERRIDE will set the default used by RESET, as well
> * as the current value. Note that source == PGC_S_OVERRIDE should be
> * used when setting a PGC_INTERNAL option.
> + *
> + * Keep in sync with GucSourceName in guc.c
> */
> typedef enum
> {
> ***************
> *** 83,89 ****
> PGC_S_SESSION = 8 /* SET command */
> } GucSource;
>
> -
> /* GUC vars that are actually declared in guc.c, rather than elsewhere */
> extern bool log_statement;
> extern bool log_duration;
> --- 87,92 ----
> ***************
> *** 123,129 ****
> extern void ShowGUCConfigOption(const char *name, DestReceiver *dest);
> extern void ShowAllGUCConfig(DestReceiver *dest);
> extern char *GetConfigOptionByName(const char *name, const char **varname);
> ! extern char *GetConfigOptionByNum(int varnum, const char **varname, bool *noshow);
> extern int GetNumConfigOptions(void);
>
> extern void SetPGVariable(const char *name, List *args, bool is_local);
> --- 126,132 ----
> extern void ShowGUCConfigOption(const char *name, DestReceiver *dest);
> extern void ShowAllGUCConfig(DestReceiver *dest);
> extern char *GetConfigOptionByName(const char *name, const char **varname);
> ! extern void GetConfigOptionByNum(int varnum, const char **values, bool *noshow);
> extern int GetNumConfigOptions(void);
>
> extern void SetPGVariable(const char *name, List *args, bool is_local);
> Index: src/test/regress/expected/rangefuncs.out
> ===================================================================
> RCS file: /opt/src/cvs/pgsql-server/src/test/regress/expected/rangefuncs.out,v
> retrieving revision 1.7
> diff -c -r1.7 rangefuncs.out
> *** src/test/regress/expected/rangefuncs.out 13 Feb 2003 20:45:22 -0000 1.7
> --- src/test/regress/expected/rangefuncs.out 26 Jun 2003 02:58:54 -0000
> ***************
> *** 1,4 ****
> ! SELECT * FROM pg_settings WHERE name LIKE 'enable%';
> name | setting
> ------------------+---------
> enable_hashagg | on
> --- 1,4 ----
> ! SELECT name, setting FROM pg_settings WHERE name LIKE 'enable%';
> name | setting
> ------------------+---------
> enable_hashagg | on
> Index: src/test/regress/expected/rules.out
> ===================================================================
> RCS file: /opt/src/cvs/pgsql-server/src/test/regress/expected/rules.out,v
> retrieving revision 1.75
> diff -c -r1.75 rules.out
> *** src/test/regress/expected/rules.out 26 May 2003 00:11:28 -0000 1.75
> --- src/test/regress/expected/rules.out 26 Jun 2003 04:40:11 -0000
> ***************
> *** 1273,1279 ****
> pg_indexes | SELECT n.nspname AS schemaname, c.relname AS tablename, i.relname AS indexname, pg_get_indexdef(i.oid) AS indexdef FROM (((pg_index x JOIN pg_class c ON ((c.oid = x.indrelid))) JOIN pg_class i ON ((i.oid = x.indexrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE ((c.relkind = 'r'::"char") AND (i.relkind = 'i'::"char"));
> pg_locks | SELECT l.relation, l."database", l."transaction", l.pid, l."mode", l.granted FROM pg_lock_status() l(relation oid, "database" oid, "transaction" xid, pid integer, "mode" text, granted boolean);
> pg_rules | SELECT n.nspname AS schemaname, c.relname AS tablename, r.rulename, pg_get_ruledef(r.oid) AS definition FROM ((pg_rewrite r JOIN pg_class c ON ((c.oid = r.ev_class))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (r.rulename <> '_RETURN'::name);
> ! pg_settings | SELECT a.name, a.setting FROM pg_show_all_settings() a(name text, setting text);
> pg_stat_activity | SELECT d.oid AS datid, d.datname, pg_stat_get_backend_pid(s.backendid) AS procpid, pg_stat_get_backend_userid(s.backendid) AS usesysid, u.usename, pg_stat_get_backend_activity(s.backendid) AS current_query, pg_stat_get_backend_activity_start(s.backendid) AS query_start FROM pg_database d, (SELECT pg_stat_get_backend_idset() AS backendid) s, pg_shadow u WHERE ((pg_stat_get_backend_dbid(s.backendid) = d.oid) AND (pg_stat_get_backend_userid(s.backendid) = u.usesysid));
> pg_stat_all_indexes | SELECT c.oid AS relid, i.oid AS indexrelid, n.nspname AS schemaname, c.relname, i.relname AS indexrelname, pg_stat_get_numscans(i.oid) AS idx_scan, pg_stat_get_tuples_returned(i.oid) AS idx_tup_read, pg_stat_get_tuples_fetched(i.oid) AS idx_tup_fetch FROM (((pg_class c JOIN pg_index x ON ((c.oid = x.indrelid))) JOIN pg_class i ON ((i.oid = x.indexrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (c.relkind = 'r'::"char");
> pg_stat_all_tables | SELECT c.oid AS relid, n.nspname AS schemaname, c.relname, pg_stat_get_numscans(c.oid) AS seq_scan, pg_stat_get_tuples_returned(c.oid) AS seq_tup_read, sum(pg_stat_get_numscans(i.indexrelid)) AS idx_scan, sum(pg_stat_get_tuples_fetched(i.indexrelid)) AS idx_tup_fetch, pg_stat_get_tuples_inserted(c.oid) AS n_tup_ins, pg_stat_get_tuples_updated(c.oid) AS n_tup_upd, pg_stat_get_tuples_deleted(c.oid) AS n_tup_del FROM ((pg_class c LEFT JOIN pg_index i ON ((c.oid = i.indrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (c.relkind = 'r'::"char") GROUP BY c.oid, n.nspname, c.relname;
> --- 1273,1279 ----
> pg_indexes | SELECT n.nspname AS schemaname, c.relname AS tablename, i.relname AS indexname, pg_get_indexdef(i.oid) AS indexdef FROM (((pg_index x JOIN pg_class c ON ((c.oid = x.indrelid))) JOIN pg_class i ON ((i.oid = x.indexrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE ((c.relkind = 'r'::"char") AND (i.relkind = 'i'::"char"));
> pg_locks | SELECT l.relation, l."database", l."transaction", l.pid, l."mode", l.granted FROM pg_lock_status() l(relation oid, "database" oid, "transaction" xid, pid integer, "mode" text, granted boolean);
> pg_rules | SELECT n.nspname AS schemaname, c.relname AS tablename, r.rulename, pg_get_ruledef(r.oid) AS definition FROM ((pg_rewrite r JOIN pg_class c ON ((c.oid = r.ev_class))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (r.rulename <> '_RETURN'::name);
> ! pg_settings | SELECT a.name, a.setting, a.context, a.vartype, a.source, a.min_val, a.max_val FROM pg_show_all_settings() a(name text, setting text, context text, vartype text, source text, min_val text, max_val text);
> pg_stat_activity | SELECT d.oid AS datid, d.datname, pg_stat_get_backend_pid(s.backendid) AS procpid, pg_stat_get_backend_userid(s.backendid) AS usesysid, u.usename, pg_stat_get_backend_activity(s.backendid) AS current_query, pg_stat_get_backend_activity_start(s.backendid) AS query_start FROM pg_database d, (SELECT pg_stat_get_backend_idset() AS backendid) s, pg_shadow u WHERE ((pg_stat_get_backend_dbid(s.backendid) = d.oid) AND (pg_stat_get_backend_userid(s.backendid) = u.usesysid));
> pg_stat_all_indexes | SELECT c.oid AS relid, i.oid AS indexrelid, n.nspname AS schemaname, c.relname, i.relname AS indexrelname, pg_stat_get_numscans(i.oid) AS idx_scan, pg_stat_get_tuples_returned(i.oid) AS idx_tup_read, pg_stat_get_tuples_fetched(i.oid) AS idx_tup_fetch FROM (((pg_class c JOIN pg_index x ON ((c.oid = x.indrelid))) JOIN pg_class i ON ((i.oid = x.indexrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (c.relkind = 'r'::"char");
> pg_stat_all_tables | SELECT c.oid AS relid, n.nspname AS schemaname, c.relname, pg_stat_get_numscans(c.oid) AS seq_scan, pg_stat_get_tuples_returned(c.oid) AS seq_tup_read, sum(pg_stat_get_numscans(i.indexrelid)) AS idx_scan, sum(pg_stat_get_tuples_fetched(i.indexrelid)) AS idx_tup_fetch, pg_stat_get_tuples_inserted(c.oid) AS n_tup_ins, pg_stat_get_tuples_updated(c.oid) AS n_tup_upd, pg_stat_get_tuples_deleted(c.oid) AS n_tup_del FROM ((pg_class c LEFT JOIN pg_index i ON ((c.oid = i.indrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (c.relkind = 'r'::"char") GROUP BY c.oid, n.nspname, c.relname;
> Index: src/test/regress/sql/rangefuncs.sql
> ===================================================================
> RCS file: /opt/src/cvs/pgsql-server/src/test/regress/sql/rangefuncs.sql,v
> retrieving revision 1.4
> diff -c -r1.4 rangefuncs.sql
> *** src/test/regress/sql/rangefuncs.sql 30 Aug 2002 19:56:49 -0000 1.4
> --- src/test/regress/sql/rangefuncs.sql 26 Jun 2003 02:58:54 -0000
> ***************
> *** 1,4 ****
> ! SELECT * FROM pg_settings WHERE name LIKE 'enable%';
>
> CREATE TABLE foo2(fooid int, f2 int);
> INSERT INTO foo2 VALUES(1, 11);
> --- 1,4 ----
> ! SELECT name, setting FROM pg_settings WHERE name LIKE 'enable%';
>
> CREATE TABLE foo2(fooid int, f2 int);
> INSERT INTO foo2 VALUES(1, 11);
>

>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073


From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] allowed user/db variables
Date: 2003-07-20 00:48:39
Message-ID: 200307200048.h6K0mdv00346@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:
> This reminds me, someone (Barry?) was griping that SHOW DATESTYLE
> doesn't produce a value that SET DATESTYLE will take. Did we agree
> that it was OK to change the output to look like "ISO, US" etc?

Is this a TODO?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] allowed user/db variables
Date: 2003-07-20 03:19:59
Message-ID: 17809.1058671199@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> This reminds me, someone (Barry?) was griping that SHOW DATESTYLE
>> doesn't produce a value that SET DATESTYLE will take. Did we agree
>> that it was OK to change the output to look like "ISO, US" etc?

> Is this a TODO?

No, it's a DONE.

regards, tom lane


From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] allowed user/db variables
Date: 2003-07-20 04:00:57
Message-ID: 200307200400.h6K40va19355@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom Lane wrote:
> >> This reminds me, someone (Barry?) was griping that SHOW DATESTYLE
> >> doesn't produce a value that SET DATESTYLE will take. Did we agree
> >> that it was OK to change the output to look like "ISO, US" etc?
>
> > Is this a TODO?
>
> No, it's a DONE.

I just tried this with CVS:

test=> show datestyle;
DateStyle
---------------------------------------
ISO with US (NonEuropean) conventions
(1 row)

test=> set datestyle = 'ISO with US (NonEuropean) conventions';
ERROR: SET DATESTYLE: invalid list syntax

Am I missing something?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] allowed user/db variables
Date: 2003-07-20 04:23:00
Message-ID: 19757.1058674980@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> No, it's a DONE.

> I just tried this with CVS:

> test=> show datestyle;
> DateStyle
> ---------------------------------------
> ISO with US (NonEuropean) conventions
> (1 row)

Uh, when was your last update? I get

regression=# show datestyle;
DateStyle
-----------
ISO, US
(1 row)

regression=#

regards, tom lane


From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] allowed user/db variables
Date: 2003-07-20 04:36:48
Message-ID: 200307200436.h6K4amX16200@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches


Oh, I see now. My new 'make check' script doesn't install a new version
in my standard path but just in the regression database.

I see what you see now.

---------------------------------------------------------------------------

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom Lane wrote:
> >> No, it's a DONE.
>
> > I just tried this with CVS:
>
> > test=> show datestyle;
> > DateStyle
> > ---------------------------------------
> > ISO with US (NonEuropean) conventions
> > (1 row)
>
> Uh, when was your last update? I get
>
> regression=# show datestyle;
> DateStyle
> -----------
> ISO, US
> (1 row)
>
> regression=#
>
> regards, tom lane
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073


From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] allowed user/db variables
Date: 2003-07-27 04:35:54
Message-ID: 200307270435.h6R4ZsR05481@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches


Patch applied. Thanks.

---------------------------------------------------------------------------

Joe Conway wrote:
> I'm going to resend the patches that I have outstanding since it appears
> some may have been lost. Here's the third of three.
> ===================================================
>
>
> Tom Lane wrote:
> > Joe Conway <mail(at)joeconway(dot)com> writes:
> >>ISTM that "source" is worth knowing.
> >
> > Hm, possibly. Any other opinions?
>
> This version has the seven fields I proposed, including "source". Here's
> an example that shows why I think it's valuable:
>
> regression=# \x
> Expanded display is on.
> regression=# select * from pg_settings where name = 'enable_seqscan';
> -[ RECORD 1 ]-----------
> name | enable_seqscan
> setting | on
> context | user
> vartype | bool
> source | default
> min_val |
> max_val |
>
> regression=# update pg_settings set setting = 'off' where name =
> 'enable_seqscan';
> -[ RECORD 1 ]---
> set_config | off
>
> regression=# select * from pg_settings where name = 'enable_seqscan';
> -[ RECORD 1 ]-----------
> name | enable_seqscan
> setting | off
> context | user
> vartype | bool
> source | session
> min_val |
> max_val |
>
> regression=# alter user postgres set enable_seqscan to 'off';
> ALTER USER
>
> (log out and then back in again)
>
> regression=# \x
> Expanded display is on.
> regression=# select * from pg_settings where name = 'enable_seqscan';
> -[ RECORD 1 ]-----------
> name | enable_seqscan
> setting | off
> context | user
> vartype | bool
> source | user
> min_val |
> max_val |
>
> In the first case, enable_seqscan is set to its default value. After
> setting it to off, it is obvious that the value has been changed for the
> session only. In the third case, you can see that the value has been set
> specifically for the user.
>
> This version of the patch also includes documentation changes. Passes
> all regression tests. Please apply.
>
> Joe
>

> Index: doc/src/sgml/runtime.sgml
> ===================================================================
> RCS file: /opt/src/cvs/pgsql-server/doc/src/sgml/runtime.sgml,v
> retrieving revision 1.187
> diff -c -r1.187 runtime.sgml
> *** doc/src/sgml/runtime.sgml 25 Jun 2003 01:13:24 -0000 1.187
> --- doc/src/sgml/runtime.sgml 26 Jun 2003 05:01:56 -0000
> ***************
> *** 571,584 ****
> <row>
> <entry><literal>name</literal></entry>
> <entry><type>text</type></entry>
> ! <entry>The name of the run-time configuration parameter</entry>
> </row>
>
> <row>
> <entry><literal>setting</literal></entry>
> <entry><type>text</type></entry>
> ! <entry>The current value of the run-time configuration parameter</entry>
> </row>
> </tbody>
> </tgroup>
> </table>
> --- 571,615 ----
> <row>
> <entry><literal>name</literal></entry>
> <entry><type>text</type></entry>
> ! <entry>run-time configuration parameter name</entry>
> </row>
>
> <row>
> <entry><literal>setting</literal></entry>
> <entry><type>text</type></entry>
> ! <entry>current value of the parameter</entry>
> </row>
> +
> + <row>
> + <entry><literal>context</literal></entry>
> + <entry><type>text</type></entry>
> + <entry>context required to set the parameter's value</entry>
> + </row>
> +
> + <row>
> + <entry><literal>vartype</literal></entry>
> + <entry><type>text</type></entry>
> + <entry>parameter type</entry>
> + </row>
> +
> + <row>
> + <entry><literal>source</literal></entry>
> + <entry><type>text</type></entry>
> + <entry>source of the current parameter value</entry>
> + </row>
> +
> + <row>
> + <entry><literal>min_val</literal></entry>
> + <entry><type>text</type></entry>
> + <entry>minimum allowed value of the parameter</entry>
> + </row>
> +
> + <row>
> + <entry><literal>max_val</literal></entry>
> + <entry><type>text</type></entry>
> + <entry>maximum allowed value of the parameter</entry>
> + </row>
> +
> </tbody>
> </tgroup>
> </table>
> Index: src/backend/utils/misc/guc.c
> ===================================================================
> RCS file: /opt/src/cvs/pgsql-server/src/backend/utils/misc/guc.c,v
> retrieving revision 1.131
> diff -c -r1.131 guc.c
> *** src/backend/utils/misc/guc.c 11 Jun 2003 22:13:22 -0000 1.131
> --- src/backend/utils/misc/guc.c 26 Jun 2003 04:03:00 -0000
> ***************
> *** 159,168 ****
> */
> enum config_type
> {
> ! PGC_BOOL,
> ! PGC_INT,
> ! PGC_REAL,
> ! PGC_STRING
> };
>
> /* Generic fields applicable to all types of variables */
> --- 159,208 ----
> */
> enum config_type
> {
> ! PGC_BOOL = 0,
> ! PGC_INT = 1,
> ! PGC_REAL = 2,
> ! PGC_STRING = 3
> ! };
> !
> ! /*
> ! * Used for pg_settings. Keep in sync with config_type enum above
> ! */
> ! static char *config_type_name[] =
> ! {
> ! "bool",
> ! "integer",
> ! "real",
> ! "string"
> ! };
> !
> ! /*
> ! * Used for pg_settings. Keep in sync with GucContext enum in guc.h
> ! */
> ! static char *GucContextName[] =
> ! {
> ! "internal",
> ! "postmaster",
> ! "sighup",
> ! "backend",
> ! "super-user",
> ! "user"
> ! };
> !
> ! /*
> ! * Used for pg_settings. Keep in sync with GucSource enum in guc.h
> ! */
> ! static char *GucSourceName[] =
> ! {
> ! "default",
> ! "environment variable",
> ! "configuration file",
> ! "command line",
> ! "database",
> ! "user",
> ! "client",
> ! "override",
> ! "session"
> };
>
> /* Generic fields applicable to all types of variables */
> ***************
> *** 2617,2639 ****
> * Return GUC variable value by variable number; optionally return canonical
> * form of name. Return value is palloc'd.
> */
> ! char *
> ! GetConfigOptionByNum(int varnum, const char **varname, bool *noshow)
> {
> ! struct config_generic *conf;
>
> /* check requested variable number valid */
> Assert((varnum >= 0) && (varnum < num_guc_variables));
>
> conf = guc_variables[varnum];
>
> - if (varname)
> - *varname = conf->name;
> -
> if (noshow)
> *noshow = (conf->flags & GUC_NO_SHOW_ALL) ? true : false;
>
> ! return _ShowOption(conf);
> }
>
> /*
> --- 2657,2758 ----
> * Return GUC variable value by variable number; optionally return canonical
> * form of name. Return value is palloc'd.
> */
> ! void
> ! GetConfigOptionByNum(int varnum, const char **values, bool *noshow)
> {
> ! char buffer[256];
> ! struct config_generic *conf;
>
> /* check requested variable number valid */
> Assert((varnum >= 0) && (varnum < num_guc_variables));
>
> conf = guc_variables[varnum];
>
> if (noshow)
> *noshow = (conf->flags & GUC_NO_SHOW_ALL) ? true : false;
>
> ! /* first get the generic attributes */
> !
> ! /* name */
> ! values[0] = conf->name;
> !
> ! /* setting : use _ShowOption in order to avoid duplicating the logic */
> ! values[1] = _ShowOption(conf);
> !
> ! /* context */
> ! values[2] = GucContextName[conf->context];
> !
> ! /* vartype */
> ! values[3] = config_type_name[conf->vartype];
> !
> ! /* source */
> ! values[4] = GucSourceName[conf->source];
> !
> ! /* now get the type specifc attributes */
> ! switch (conf->vartype)
> ! {
> ! case PGC_BOOL:
> ! {
> ! /* min_val */
> ! values[5] = NULL;
> !
> ! /* max_val */
> ! values[6] = NULL;
> ! }
> ! break;
> !
> ! case PGC_INT:
> ! {
> ! struct config_int *lconf = (struct config_int *) conf;
> !
> ! /* min_val */
> ! snprintf(buffer, sizeof(buffer), "%d", lconf->min);
> ! values[5] = pstrdup(buffer);
> !
> ! /* max_val */
> ! snprintf(buffer, sizeof(buffer), "%d", lconf->max);
> ! values[6] = pstrdup(buffer);
> ! }
> ! break;
> !
> ! case PGC_REAL:
> ! {
> ! struct config_real *lconf = (struct config_real *) conf;
> !
> ! /* min_val */
> ! snprintf(buffer, sizeof(buffer), "%g", lconf->min);
> ! values[5] = pstrdup(buffer);
> !
> ! /* max_val */
> ! snprintf(buffer, sizeof(buffer), "%g", lconf->max);
> ! values[6] = pstrdup(buffer);
> ! }
> ! break;
> !
> ! case PGC_STRING:
> ! {
> ! /* min_val */
> ! values[5] = NULL;
> !
> ! /* max_val */
> ! values[6] = NULL;
> ! }
> ! break;
> !
> ! default:
> ! {
> ! /*
> ! * should never get here, but in case we do, set 'em to NULL
> ! */
> !
> ! /* min_val */
> ! values[5] = NULL;
> !
> ! /* max_val */
> ! values[6] = NULL;
> ! }
> ! break;
> ! }
> }
>
> /*
> ***************
> *** 2673,2678 ****
> --- 2792,2799 ----
> * show_all_settings - equiv to SHOW ALL command but implemented as
> * a Table Function.
> */
> + #define NUM_PG_SETTINGS_ATTS 7
> +
> Datum
> show_all_settings(PG_FUNCTION_ARGS)
> {
> ***************
> *** 2696,2707 ****
> */
> oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
>
> ! /* need a tuple descriptor representing two TEXT columns */
> ! tupdesc = CreateTemplateTupleDesc(2, false);
> TupleDescInitEntry(tupdesc, (AttrNumber) 1, "name",
> TEXTOID, -1, 0, false);
> TupleDescInitEntry(tupdesc, (AttrNumber) 2, "setting",
> TEXTOID, -1, 0, false);
>
> /* allocate a slot for a tuple with this tupdesc */
> slot = TupleDescGetSlot(tupdesc);
> --- 2817,2841 ----
> */
> oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
>
> ! /*
> ! * need a tuple descriptor representing NUM_PG_SETTINGS_ATTS columns
> ! * of the appropriate types
> ! */
> ! tupdesc = CreateTemplateTupleDesc(NUM_PG_SETTINGS_ATTS, false);
> TupleDescInitEntry(tupdesc, (AttrNumber) 1, "name",
> TEXTOID, -1, 0, false);
> TupleDescInitEntry(tupdesc, (AttrNumber) 2, "setting",
> TEXTOID, -1, 0, false);
> + TupleDescInitEntry(tupdesc, (AttrNumber) 3, "context",
> + TEXTOID, -1, 0, false);
> + TupleDescInitEntry(tupdesc, (AttrNumber) 4, "vartype",
> + TEXTOID, -1, 0, false);
> + TupleDescInitEntry(tupdesc, (AttrNumber) 5, "source",
> + TEXTOID, -1, 0, false);
> + TupleDescInitEntry(tupdesc, (AttrNumber) 6, "min_val",
> + TEXTOID, -1, 0, false);
> + TupleDescInitEntry(tupdesc, (AttrNumber) 7, "max_val",
> + TEXTOID, -1, 0, false);
>
> /* allocate a slot for a tuple with this tupdesc */
> slot = TupleDescGetSlot(tupdesc);
> ***************
> *** 2732,2740 ****
>
> if (call_cntr < max_calls) /* do when there is more left to send */
> {
> ! char *values[2];
> ! char *varname;
> ! char *varval;
> bool noshow;
> HeapTuple tuple;
> Datum result;
> --- 2866,2872 ----
>
> if (call_cntr < max_calls) /* do when there is more left to send */
> {
> ! char *values[NUM_PG_SETTINGS_ATTS];
> bool noshow;
> HeapTuple tuple;
> Datum result;
> ***************
> *** 2744,2758 ****
> */
> do
> {
> ! varval = GetConfigOptionByNum(call_cntr,
> ! (const char **) &varname,
> ! &noshow);
> if (noshow)
> {
> - /* varval is a palloc'd copy, so free it */
> - if (varval != NULL)
> - pfree(varval);
> -
> /* bump the counter and get the next config setting */
> call_cntr = ++funcctx->call_cntr;
>
> --- 2876,2884 ----
> */
> do
> {
> ! GetConfigOptionByNum(call_cntr, (const char **) values, &noshow);
> if (noshow)
> {
> /* bump the counter and get the next config setting */
> call_cntr = ++funcctx->call_cntr;
>
> ***************
> *** 2762,2784 ****
> }
> } while (noshow);
>
> - /*
> - * Prepare a values array for storage in our slot. This should be
> - * an array of C strings which will be processed later by the
> - * appropriate "in" functions.
> - */
> - values[0] = varname;
> - values[1] = varval;
> -
> /* build a tuple */
> tuple = BuildTupleFromCStrings(attinmeta, values);
>
> /* make the tuple into a datum */
> result = TupleGetDatum(slot, tuple);
> -
> - /* Clean up */
> - if (varval != NULL)
> - pfree(varval);
>
> SRF_RETURN_NEXT(funcctx, result);
> }
> --- 2888,2898 ----
> Index: src/bin/initdb/initdb.sh
> ===================================================================
> RCS file: /opt/src/cvs/pgsql-server/src/bin/initdb/initdb.sh,v
> retrieving revision 1.192
> diff -c -r1.192 initdb.sh
> *** src/bin/initdb/initdb.sh 2 Jun 2003 19:00:29 -0000 1.192
> --- src/bin/initdb/initdb.sh 26 Jun 2003 03:56:23 -0000
> ***************
> *** 971,977 ****
>
> CREATE VIEW pg_settings AS \
> SELECT * \
> ! FROM pg_show_all_settings() AS A(name text, setting text);
>
> CREATE RULE pg_settings_u AS \
> ON UPDATE TO pg_settings \
> --- 971,979 ----
>
> CREATE VIEW pg_settings AS \
> SELECT * \
> ! FROM pg_show_all_settings() AS A \
> ! (name text, setting text, context text, vartype text, \
> ! source text, min_val text, max_val text);
>
> CREATE RULE pg_settings_u AS \
> ON UPDATE TO pg_settings \
> Index: src/include/utils/guc.h
> ===================================================================
> RCS file: /opt/src/cvs/pgsql-server/src/include/utils/guc.h,v
> retrieving revision 1.32
> diff -c -r1.32 guc.h
> *** src/include/utils/guc.h 11 Jun 2003 18:01:14 -0000 1.32
> --- src/include/utils/guc.h 26 Jun 2003 02:58:54 -0000
> ***************
> *** 49,63 ****
> * we don't yet know if the user is a superuser.
> *
> * USERSET options can be set by anyone any time.
> */
> typedef enum
> {
> ! PGC_INTERNAL,
> ! PGC_POSTMASTER,
> ! PGC_SIGHUP,
> ! PGC_BACKEND,
> ! PGC_SUSET,
> ! PGC_USERSET
> } GucContext;
>
> /*
> --- 49,65 ----
> * we don't yet know if the user is a superuser.
> *
> * USERSET options can be set by anyone any time.
> + *
> + * Keep in sync with GucContextName in guc.c
> */
> typedef enum
> {
> ! PGC_INTERNAL = 0,
> ! PGC_POSTMASTER = 1,
> ! PGC_SIGHUP = 2,
> ! PGC_BACKEND = 3,
> ! PGC_SUSET = 4,
> ! PGC_USERSET = 5
> } GucContext;
>
> /*
> ***************
> *** 69,74 ****
> --- 71,78 ----
> * Sources <= PGC_S_OVERRIDE will set the default used by RESET, as well
> * as the current value. Note that source == PGC_S_OVERRIDE should be
> * used when setting a PGC_INTERNAL option.
> + *
> + * Keep in sync with GucSourceName in guc.c
> */
> typedef enum
> {
> ***************
> *** 83,89 ****
> PGC_S_SESSION = 8 /* SET command */
> } GucSource;
>
> -
> /* GUC vars that are actually declared in guc.c, rather than elsewhere */
> extern bool log_statement;
> extern bool log_duration;
> --- 87,92 ----
> ***************
> *** 123,129 ****
> extern void ShowGUCConfigOption(const char *name, DestReceiver *dest);
> extern void ShowAllGUCConfig(DestReceiver *dest);
> extern char *GetConfigOptionByName(const char *name, const char **varname);
> ! extern char *GetConfigOptionByNum(int varnum, const char **varname, bool *noshow);
> extern int GetNumConfigOptions(void);
>
> extern void SetPGVariable(const char *name, List *args, bool is_local);
> --- 126,132 ----
> extern void ShowGUCConfigOption(const char *name, DestReceiver *dest);
> extern void ShowAllGUCConfig(DestReceiver *dest);
> extern char *GetConfigOptionByName(const char *name, const char **varname);
> ! extern void GetConfigOptionByNum(int varnum, const char **values, bool *noshow);
> extern int GetNumConfigOptions(void);
>
> extern void SetPGVariable(const char *name, List *args, bool is_local);
> Index: src/test/regress/expected/rangefuncs.out
> ===================================================================
> RCS file: /opt/src/cvs/pgsql-server/src/test/regress/expected/rangefuncs.out,v
> retrieving revision 1.7
> diff -c -r1.7 rangefuncs.out
> *** src/test/regress/expected/rangefuncs.out 13 Feb 2003 20:45:22 -0000 1.7
> --- src/test/regress/expected/rangefuncs.out 26 Jun 2003 02:58:54 -0000
> ***************
> *** 1,4 ****
> ! SELECT * FROM pg_settings WHERE name LIKE 'enable%';
> name | setting
> ------------------+---------
> enable_hashagg | on
> --- 1,4 ----
> ! SELECT name, setting FROM pg_settings WHERE name LIKE 'enable%';
> name | setting
> ------------------+---------
> enable_hashagg | on
> Index: src/test/regress/expected/rules.out
> ===================================================================
> RCS file: /opt/src/cvs/pgsql-server/src/test/regress/expected/rules.out,v
> retrieving revision 1.75
> diff -c -r1.75 rules.out
> *** src/test/regress/expected/rules.out 26 May 2003 00:11:28 -0000 1.75
> --- src/test/regress/expected/rules.out 26 Jun 2003 04:40:11 -0000
> ***************
> *** 1273,1279 ****
> pg_indexes | SELECT n.nspname AS schemaname, c.relname AS tablename, i.relname AS indexname, pg_get_indexdef(i.oid) AS indexdef FROM (((pg_index x JOIN pg_class c ON ((c.oid = x.indrelid))) JOIN pg_class i ON ((i.oid = x.indexrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE ((c.relkind = 'r'::"char") AND (i.relkind = 'i'::"char"));
> pg_locks | SELECT l.relation, l."database", l."transaction", l.pid, l."mode", l.granted FROM pg_lock_status() l(relation oid, "database" oid, "transaction" xid, pid integer, "mode" text, granted boolean);
> pg_rules | SELECT n.nspname AS schemaname, c.relname AS tablename, r.rulename, pg_get_ruledef(r.oid) AS definition FROM ((pg_rewrite r JOIN pg_class c ON ((c.oid = r.ev_class))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (r.rulename <> '_RETURN'::name);
> ! pg_settings | SELECT a.name, a.setting FROM pg_show_all_settings() a(name text, setting text);
> pg_stat_activity | SELECT d.oid AS datid, d.datname, pg_stat_get_backend_pid(s.backendid) AS procpid, pg_stat_get_backend_userid(s.backendid) AS usesysid, u.usename, pg_stat_get_backend_activity(s.backendid) AS current_query, pg_stat_get_backend_activity_start(s.backendid) AS query_start FROM pg_database d, (SELECT pg_stat_get_backend_idset() AS backendid) s, pg_shadow u WHERE ((pg_stat_get_backend_dbid(s.backendid) = d.oid) AND (pg_stat_get_backend_userid(s.backendid) = u.usesysid));
> pg_stat_all_indexes | SELECT c.oid AS relid, i.oid AS indexrelid, n.nspname AS schemaname, c.relname, i.relname AS indexrelname, pg_stat_get_numscans(i.oid) AS idx_scan, pg_stat_get_tuples_returned(i.oid) AS idx_tup_read, pg_stat_get_tuples_fetched(i.oid) AS idx_tup_fetch FROM (((pg_class c JOIN pg_index x ON ((c.oid = x.indrelid))) JOIN pg_class i ON ((i.oid = x.indexrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (c.relkind = 'r'::"char");
> pg_stat_all_tables | SELECT c.oid AS relid, n.nspname AS schemaname, c.relname, pg_stat_get_numscans(c.oid) AS seq_scan, pg_stat_get_tuples_returned(c.oid) AS seq_tup_read, sum(pg_stat_get_numscans(i.indexrelid)) AS idx_scan, sum(pg_stat_get_tuples_fetched(i.indexrelid)) AS idx_tup_fetch, pg_stat_get_tuples_inserted(c.oid) AS n_tup_ins, pg_stat_get_tuples_updated(c.oid) AS n_tup_upd, pg_stat_get_tuples_deleted(c.oid) AS n_tup_del FROM ((pg_class c LEFT JOIN pg_index i ON ((c.oid = i.indrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (c.relkind = 'r'::"char") GROUP BY c.oid, n.nspname, c.relname;
> --- 1273,1279 ----
> pg_indexes | SELECT n.nspname AS schemaname, c.relname AS tablename, i.relname AS indexname, pg_get_indexdef(i.oid) AS indexdef FROM (((pg_index x JOIN pg_class c ON ((c.oid = x.indrelid))) JOIN pg_class i ON ((i.oid = x.indexrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE ((c.relkind = 'r'::"char") AND (i.relkind = 'i'::"char"));
> pg_locks | SELECT l.relation, l."database", l."transaction", l.pid, l."mode", l.granted FROM pg_lock_status() l(relation oid, "database" oid, "transaction" xid, pid integer, "mode" text, granted boolean);
> pg_rules | SELECT n.nspname AS schemaname, c.relname AS tablename, r.rulename, pg_get_ruledef(r.oid) AS definition FROM ((pg_rewrite r JOIN pg_class c ON ((c.oid = r.ev_class))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (r.rulename <> '_RETURN'::name);
> ! pg_settings | SELECT a.name, a.setting, a.context, a.vartype, a.source, a.min_val, a.max_val FROM pg_show_all_settings() a(name text, setting text, context text, vartype text, source text, min_val text, max_val text);
> pg_stat_activity | SELECT d.oid AS datid, d.datname, pg_stat_get_backend_pid(s.backendid) AS procpid, pg_stat_get_backend_userid(s.backendid) AS usesysid, u.usename, pg_stat_get_backend_activity(s.backendid) AS current_query, pg_stat_get_backend_activity_start(s.backendid) AS query_start FROM pg_database d, (SELECT pg_stat_get_backend_idset() AS backendid) s, pg_shadow u WHERE ((pg_stat_get_backend_dbid(s.backendid) = d.oid) AND (pg_stat_get_backend_userid(s.backendid) = u.usesysid));
> pg_stat_all_indexes | SELECT c.oid AS relid, i.oid AS indexrelid, n.nspname AS schemaname, c.relname, i.relname AS indexrelname, pg_stat_get_numscans(i.oid) AS idx_scan, pg_stat_get_tuples_returned(i.oid) AS idx_tup_read, pg_stat_get_tuples_fetched(i.oid) AS idx_tup_fetch FROM (((pg_class c JOIN pg_index x ON ((c.oid = x.indrelid))) JOIN pg_class i ON ((i.oid = x.indexrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (c.relkind = 'r'::"char");
> pg_stat_all_tables | SELECT c.oid AS relid, n.nspname AS schemaname, c.relname, pg_stat_get_numscans(c.oid) AS seq_scan, pg_stat_get_tuples_returned(c.oid) AS seq_tup_read, sum(pg_stat_get_numscans(i.indexrelid)) AS idx_scan, sum(pg_stat_get_tuples_fetched(i.indexrelid)) AS idx_tup_fetch, pg_stat_get_tuples_inserted(c.oid) AS n_tup_ins, pg_stat_get_tuples_updated(c.oid) AS n_tup_upd, pg_stat_get_tuples_deleted(c.oid) AS n_tup_del FROM ((pg_class c LEFT JOIN pg_index i ON ((c.oid = i.indrelid))) LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) WHERE (c.relkind = 'r'::"char") GROUP BY c.oid, n.nspname, c.relname;
> Index: src/test/regress/sql/rangefuncs.sql
> ===================================================================
> RCS file: /opt/src/cvs/pgsql-server/src/test/regress/sql/rangefuncs.sql,v
> retrieving revision 1.4
> diff -c -r1.4 rangefuncs.sql
> *** src/test/regress/sql/rangefuncs.sql 30 Aug 2002 19:56:49 -0000 1.4
> --- src/test/regress/sql/rangefuncs.sql 26 Jun 2003 02:58:54 -0000
> ***************
> *** 1,4 ****
> ! SELECT * FROM pg_settings WHERE name LIKE 'enable%';
>
> CREATE TABLE foo2(fooid int, f2 int);
> INSERT INTO foo2 VALUES(1, 11);
> --- 1,4 ----
> ! SELECT name, setting FROM pg_settings WHERE name LIKE 'enable%';
>
> CREATE TABLE foo2(fooid int, f2 int);
> INSERT INTO foo2 VALUES(1, 11);
>

>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073


From: Joe Conway <mail(at)joeconway(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] allowed user/db variables
Date: 2003-07-27 05:29:48
Message-ID: 3F23634C.7030805@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

Bruce Momjian wrote:
> Patch applied. Thanks.
>

There was enough code drift since this patch, that a couple of bugs
materialized.

New items have been added to GucContext and GucSource enums, but of
course they were not added to the corresponding GucContextName[] and
GucSourceName[] arrays in the patch. Here's a new patch to fix the
resulting bugs.

Joe

Attachment Content-Type Size
pg_settings-bugfix.1.patch text/plain 2.0 KB

From: Aizaz Ahmed <aahmed(at)redhat(dot)com>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org, Fernando Nasser <fnasser(at)redhat(dot)com>, Aizaz Ahmed <aahmed(at)redhat(dot)com>
Subject: Re: [HACKERS] allowed user/db variables
Date: 2003-07-28 14:41:29
Message-ID: 1059403288.19897.11.camel@toffee.toronto.redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

On Sun, 2003-07-27 at 01:29, Joe Conway wrote:
> Bruce Momjian wrote:
> > Patch applied. Thanks.

> /*
> ! * Used for pg_settings. Keep in sync with config_type enum in guc_tables.h
> */
> static char *config_type_name[] =
> {
> ***************
> *** 176,181 ****
> --- 176,182 ----
> "sighup",
> "backend",
> "super-user",
> + "userlimit",
> "user"
> };

looks like there's some duplication between this array and the
static const char *const GucContext_names[] array in
src/backend/utils/misc/help_config.c

Is there some way we could have them both use the same array? (it
doesn't matter for help_config whether the names are upper- or
lower-case.)

Also, as a side note, I don't think Tom is a big fan of using comments
to indicate what needs to be kept in sync with what, if I can take the
liberty to quote him the last time a situation like this arose:

Re: [PATCHES] fix for new SUSET GUC variables
Mon, 14 Jul 2003 16:33:14 -0400

> We don't normally try to enumerate in comments all the places you'd
> need to change when adding to an enum or other widely-used
> definition. You're supposed to find them by searching the source code
> for references to the existing values. Depending on comments for that
> sort of thing is far too error-prone --- you can just about guarantee
> that the comment will fail to track new uses.

Thanks,
Aizaz


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Aizaz Ahmed <aahmed(at)redhat(dot)com>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org, Fernando Nasser <fnasser(at)redhat(dot)com>
Subject: Re: [HACKERS] allowed user/db variables
Date: 2003-07-28 14:57:28
Message-ID: 9502.1059404248@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

Aizaz Ahmed <aahmed(at)redhat(dot)com> writes:
> looks like there's some duplication between this array and the
> static const char *const GucContext_names[] array in
> src/backend/utils/misc/help_config.c
> Is there some way we could have them both use the same array?

Good idea. Please send a patch that exports the guc.c array for use in
the other file. I'd lean towards the lower-cased spellings, though I'm
not strong about it. (I'd also not use a dash in "super-user".)

> Also, as a side note, I don't think Tom is a big fan of using comments
> to indicate what needs to be kept in sync with what, if I can take the
> liberty to quote him the last time a situation like this arose:

I still stand by that opinion. We've seen a couple failures now with
respect to these arrays, but I think that comes from having people
independently patching the same code with too long delay between patch
submission and application. The comment wouldn't have prevented the
error, because patch(1) can't read comments.

regards, tom lane


From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] allowed user/db variables
Date: 2003-07-28 16:22:05
Message-ID: 200307281622.h6SGM5107977@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches


Patch applied. Thanks.

---------------------------------------------------------------------------

Joe Conway wrote:
> Bruce Momjian wrote:
> > Patch applied. Thanks.
> >
>
> There was enough code drift since this patch, that a couple of bugs
> materialized.
>
> New items have been added to GucContext and GucSource enums, but of
> course they were not added to the corresponding GucContextName[] and
> GucSourceName[] arrays in the patch. Here's a new patch to fix the
> resulting bugs.
>
> Joe
>
>

> Index: src/backend/utils/misc/guc.c
> ===================================================================
> RCS file: /opt/src/cvs/pgsql-server/src/backend/utils/misc/guc.c,v
> retrieving revision 1.140
> diff -c -r1.140 guc.c
> *** src/backend/utils/misc/guc.c 27 Jul 2003 04:35:53 -0000 1.140
> --- src/backend/utils/misc/guc.c 27 Jul 2003 05:22:12 -0000
> ***************
> *** 156,162 ****
>
>
> /*
> ! * Used for pg_settings. Keep in sync with config_type enum above
> */
> static char *config_type_name[] =
> {
> --- 156,162 ----
>
>
> /*
> ! * Used for pg_settings. Keep in sync with config_type enum in guc_tables.h
> */
> static char *config_type_name[] =
> {
> ***************
> *** 176,181 ****
> --- 176,182 ----
> "sighup",
> "backend",
> "super-user",
> + "userlimit",
> "user"
> };
>
> ***************
> *** 188,193 ****
> --- 189,195 ----
> "environment variable",
> "configuration file",
> "command line",
> + "userstart",
> "database",
> "user",
> "client",
> Index: src/include/utils/guc.h
> ===================================================================
> RCS file: /opt/src/cvs/pgsql-server/src/include/utils/guc.h,v
> retrieving revision 1.36
> diff -c -r1.36 guc.h
> *** src/include/utils/guc.h 27 Jul 2003 04:35:54 -0000 1.36
> --- src/include/utils/guc.h 27 Jul 2003 05:23:21 -0000
> ***************
> *** 52,57 ****
> --- 52,59 ----
> * non-super users.
> *
> * USERSET options can be set by anyone any time.
> + *
> + * Keep in sync with GucContextName in guc.c
> */
> typedef enum
> {
> Index: src/include/utils/guc_tables.h
> ===================================================================
> RCS file: /opt/src/cvs/pgsql-server/src/include/utils/guc_tables.h,v
> retrieving revision 1.2
> diff -c -r1.2 guc_tables.h
> *** src/include/utils/guc_tables.h 27 Jul 2003 04:35:54 -0000 1.2
> --- src/include/utils/guc_tables.h 27 Jul 2003 05:23:51 -0000
> ***************
> *** 58,63 ****
> --- 58,65 ----
>
> /*
> * GUC supports these types of variables:
> + *
> + * Keep in sync with config_type_name in guc.c
> */
> enum config_type
> {

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073


From: Aizaz Ahmed <aahmed(at)redhat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Joe Conway <mail(at)joeconway(dot)com>, pgsql-patches(at)postgresql(dot)org, Fernando Nasser <fnasser(at)redhat(dot)com>, Aizaz Ahmed <aahmed(at)redhat(dot)com>
Subject: Re: [HACKERS] allowed user/db variables
Date: 2003-07-28 18:22:06
Message-ID: 1059416526.19897.64.camel@toffee.toronto.redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

On Mon, 2003-07-28 at 10:57, Tom Lane wrote:
> Good idea. Please send a patch that exports the guc.c array for use in
> the other file. I'd lean towards the lower-cased spellings, though I'm
> not strong about it. (I'd also not use a dash in "super-user".)

I've attached the patch below. It modifies help_config.c to use the new
GucContextName array from guc.c

It also changes 'super-user' to 'superuser'

I was waiting for Joe's earlier patch to be applied, this should be safe
to apply now.

Thanks,
Aizaz

Attachment Content-Type Size
GucContext_patch.txt text/x-patch 2.4 KB

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Aizaz Ahmed <aahmed(at)redhat(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Joe Conway <mail(at)joeconway(dot)com>, pgsql-patches(at)postgresql(dot)org, Fernando Nasser <fnasser(at)redhat(dot)com>
Subject: Re: [HACKERS] allowed user/db variables
Date: 2003-07-28 19:32:56
Message-ID: 20672.1059420776@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

Aizaz Ahmed <aahmed(at)redhat(dot)com> writes:
>> Good idea. Please send a patch that exports the guc.c array for use in
>> the other file. I'd lean towards the lower-cased spellings, though I'm
>> not strong about it. (I'd also not use a dash in "super-user".)

> I've attached the patch below. It modifies help_config.c to use the new
> GucContextName array from guc.c

Applied, thanks. I also did some other cleanup, including sticking the
enum constant names into the array declarations --- this is in service
of the notion that grepping for the constants should help you find
places you need to change when adding one.

regards, tom lane