So if there is only one versin of postgeSQL installed and no other
products with the name "postgres", which I am guessing is very typical
in most instances, can I change the uninstaller to delete/remove
everything that this installer installed?
If there is another instance, it would leave the common things around of
course, but uninstalling a single instance leaves a lot of droppings
around that need to be manually cleaned up.
J.V.
On 11/10/2011 8:18 PM, Craig Ringer wrote:
On 11/11/2011 06:18 AM, J.V. wrote:
yes, this is on windows.
Currently removing the data directory and the postgresql user is not
optional. It fails and does not remove those two items.
There must be 30+ registry keys still there as well.
What I am looking to do is to delete any registry entry:
1. that has a data value matching the pattern '*postgres*'
2. that has a directory value matching the pattern '*postgres*'
3. that has a key name matching the pattern '*postgres*'
I think that's a _bad_ idea for several reasons:
- More than one PostgreSQL version can be installed concurrently
- Other products include the name-part "postgres", such as
"Postgres Plus" among others.
- The installer cannot tell whether any other users of the mu
"postgres" user account remain. A PgAgent install may still
be present even after PostgreSQL has been uninstalled, for
example, and the user won't want it uninstalled especially
if they're about to reinstall PostgreSQL. Also, when more than
one Pg version is present it's hard to be certain whether the
running uninstaller is the _last_ one on the system and should
remove the "postgres" user account.
I don't think the usual uninstaller should behave as you describe.
That said, I do see value in a "clean" uninstall option that strips
out everything at the risk of possibly breaking parallel installs of
other products or PostgreSQL versions.
I guess in an ideal world PostgreSQL installers and uninstallers could
refcount so they knew when the last product was uninstalled. In
practice, people can't be relied on to use uninstallers properly, 3rd
party products won't manage the refcount properly, etc, and it'll land
up breaking things.
--
Craig Ringer
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
