Re: [HACKERS] allowed user/db variables
>>> 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 ---(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
Re: [HACKERS] allowed user/db variables
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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] allowed user/db variables
> 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] allowed user/db variables
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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] allowed user/db variables
> 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 ---(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
Re: [HACKERS] allowed user/db variables
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 ---(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
Re: [HACKERS] allowed user/db variables
Tom Lane wrote: "Christopher Kings-Lynne" <[EMAIL PROTECTED]> 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 ---(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
Re: [HACKERS] allowed user/db variables
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] allowed user/db variables
> 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] allowed user/db variables
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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] allowed user/db variables
Andreas Pflug <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
