Greg,

> Not sure how far along you are, but I've been writing some really nifty
> extensions to DBD::Pg that allow easy querying of all the current
> run-time settings. Could be very useful to this project, seems to me. If
> you're interested in possibly using it, let me know, I can bump it up on
> my todo list.

Um, can't we just get that from pg_settings?

Anyway, I'll be deriving settings from the .conf file, since most of the
time the Configurator will be run on a new installation.

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Josh Berkus wrote:
> Greg,
>
>
>>Not sure how far along you are, but I've been writing some really nifty
>>extensions to DBD::Pg that allow easy querying of all the current
>>run-time settings. Could be very useful to this project, seems to me. If
>>you're interested in possibly using it, let me know, I can bump it up on
>>my todo list.
>
>
> Um, can't we just get that from pg_settings?
>
> Anyway, I'll be deriving settings from the .conf file, since most of the
> time the Configurator will be run on a new installation.

Aren't most of the settings all kept in the SHOW variables anyway?

Sincerely,

Joshua D. Drake


>


--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>> Um, can't we just get that from pg_settings?
>>
>> Anyway, I'll be deriving settings from the .conf file, since most of the
>> time the Configurator will be run on a new installation.
>
> Aren't most of the settings all kept in the SHOW variables anyway?

As I said, it may not be applicable to this project, but thought I would
offer. One gotcha the module makes transparent is that in older versions of
PG, the variables are returned in a different way (via RAISE). My module
will allow you to get the configuration for any connected database, for
any configuration file, and the defaults for any known version, and do
quick comparisons between them all. So you could use it to see what has
changed between a particular server and its conf file, or the differences
between two conf files, or the differences between two databases, or even show
what has changed in the default conf file from 7.4.7 and 8.0.1. It will also
allow you to rewrite the conf files in a standard way.

I'm hoping to roll this into 1.44 or 1.45 or DBD::Pg.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200506212046
http://biglumber.com/x/web?pk=2529DF...9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iD8DBQFCuLWDvJuQZxSWSsgRAjUVAJ42oeveZBuutFo1G3Cs/3dRZWjKggCfS1Yf
Tv5RWiG9s8Ucv/t/2HZ4/R8=
=1eap
-----END PGP SIGNATURE-----



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

Greg Sabino Mullane wrote:
>
>
>>>>Um, can't we just get that from pg_settings?
>>>>
>>>>Anyway, I'll be deriving settings from the .conf file, since most of the
>>>>time the Configurator will be run on a new installation.
>>>
>>>Aren't most of the settings all kept in the SHOW variables anyway?
>
>
> As I said, it may not be applicable to this project, but thought I would
> offer. One gotcha the module makes transparent is that in older versions of
> PG, the variables are returned in a different way (via RAISE). My module
> will allow you to get the configuration for any connected database, for
> any configuration file, and the defaults for any known version, and do
> quick comparisons between them all. So you could use it to see what has
> changed between a particular server and its conf file, or the differences
> between two conf files, or the differences between two databases, or even show
> what has changed in the default conf file from 7.4.7 and 8.0.1. It will also
> allow you to rewrite the conf files in a standard way.

Sounds a little similar to what's in pgAdmin CVS right now. The
configuration editor can retrieve the config file and display configured
and active setting concurrently, together with explanations taken from
pg_settings (when not run against a pgsql server but a file current
settings are missing, comments are taken from a pg_settings csv dump).
There's the infrastructure to give hints about all settings, with very
few currently implemented.

I wonder if this could be combined with the configurator somehow.
Currently, integration won't work with Perl, so maybe C for the core and
Perl for the interactive part would be better.

Regards,
Andreas

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> Sounds a little similar to what's in pgAdmin CVS right now. The
> configuration editor can retrieve the config file and display configured
> and active setting concurrently, together with explanations taken from
> pg_settings (when not run against a pgsql server but a file current
> settings are missing, comments are taken from a pg_settings csv dump).
> There's the infrastructure to give hints about all settings, with very
> few currently implemented.
>
> I wonder if this could be combined with the configurator somehow.
> Currently, integration won't work with Perl, so maybe C for the core and
> Perl for the interactive part would be better.

Probably so. Seems there is a bit of convergent evolution going on. When I
get a moment of free time, I'll check out the pgAdmin code. Can someone
shoot me a URL to the files in question? (assuming a web cvs interface).

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200506242107
http://biglumber.com/x/web?pk=2529DF...9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iD8DBQFCvK6AvJuQZxSWSsgRApFcAKDVQ5OdVgVc2PmY/p719teJ3BqNjQCgrgyx
+w+w8GCGXUFO+5dxi5RPwKo=
=eG7M
-----END PGP SIGNATURE-----



---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Greg Sabino Mullane wrote:

>>I wonder if this could be combined with the configurator somehow.
>>Currently, integration won't work with Perl, so maybe C for the core and
>>Perl for the interactive part would be better.
>>
>>
>
>Probably so. Seems there is a bit of convergent evolution going on. When I
>get a moment of free time, I'll check out the pgAdmin code. Can someone
>shoot me a URL to the files in question? (assuming a web cvs interface).
>
>
>
http://svn.pgadmin.org/cgi-bin/viewc...17&view=markup

This is an editor only, an expert mode (e.g. recommendations for
different sizes/loads) would be nice.

Regards,
Andreas


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