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