Re: PostgreSQL pollutes the file system

Could I please ask a couple of questions?

Why does the first answer to everything seem to be "we need to destroy
something to make it better for others"? Why does createdb need to be
removed? Why do we use the "newbie that can't understand whether or not
createdb is for PostgreSQL or MySQL or ...." and then ignore the fact that
this would be the one person least able to handle a breakage of a 5 year
old internal script that simply does it's job for them each day?

What if someone has a nice little script that is really well written and
fails on warnings because the company policy is that "warnings are to be
respected"? How does that person properly do their job if they need to
break open that script one morning because we've dropped a "warning bomb"
on them without any option but to fix the entire script in one shot with no
option to continue otherwise? What if there is a semi-strict QA policy at
said company and they are placed in a bind due to the volume and nature of
the changes required here because of steps taken that are impossible to
reasonably work around (possibly even outside of the script itself)?

So I would like to offer the beginning of a "framework" of steps that could
accomplish the desired task with the bare minimum of breakage and with
simple steps that can be offered to help people affected by these changes.

1) Any new name is a symlink to the old name. We do not break existing
tooling for any non-obvious reason. Any notion of symlinking the old names
and then discussing "packagers could add a PostgreSQL-Legacy-Symlinks
package" is not ok. We cannot have users breaking because of a missing
package and then have them running around with their head cut off trying to
figure out where that package is for their particular system. We make
across the board changes that are easily explainable.

2) We can certainly add a warning to the old names that warn of future
removal. However we need to offer a simple option to remove these warnings
in a future friendly fashion. Remember the person that is not ok running
around deep inside a 1000 line script.

3) Long term (or even fairly short term) we move the old names back to a
more appropriate location - lets say /opt//pgsql/bin - if someone ignored
the warnings then they are broken - there is nothing that can be done with
that - but we've now accomplished the stated goal - hide names like
"createdb" from standard paths.

However how do we deal with the VERY bad side of #2/#3? That's what i feel
has been missing here. So lets walk through something

If someone has a script that breaks on warnings - or they are generally not
someone that is comfortable making many changes to a script - we need a
single line option for them.

WARNING - createdb is no longer the preferred method - please either change
to pg_createdb OR add the following line near the top of your
script/environment

source pg_legacy_environment

(Wording is not my strong suit - bear with me please)

What is pg_legacy_environment? Well it's a provided file that starts it's
life as simple as this

export PG_LEGACY_ENVIRONMENT=1

And the warnings that check for usage of the old command names check for
PG_LEGACY_ENVIRONMENT and understand that if that variable exists - the
user has chosen to make the minimal change to their script and should be
respected. We will fix their environment for them as needed to allow them
to continue using old names.

That solves #2 and allows for someone to very quickly remove warnings
without any major changes. A single line change is as simple as one can
imagine or do. If someone cannot accomplish this change - what possibly can
we do for them?

When #3 hits and the old names are removed from the path -
pg_legacy_environment could change to something along these lines

export PATH=$PATH:/opt/pgsql/bin

And now we have a removal of the old names, that does not break anyone that
has followed the warning until this point - and allows for a simple, one
line fix, to anyone that walks in the door and screams FIRE because they
ignored the warning and now have a problem.

I feel the above respects the people that are supposed to be the people we
have empathy for - they are also steps that can be done even fairly quickly
because the fix is handled via modification to the script environment as
opposed to the core workings of a script itself. In fact - one could add
the pg_legacy_environment line to their shell environment and not even
modify a single script at all.

John