On Sun, Dec 27, 2020 at 05:48:47PM +0900, Michael Paquier wrote: > On Sat, Dec 26, 2020 at 02:00:02PM -0500, Bruce Momjian wrote: > > On Sat, Dec 26, 2020 at 12:18:18PM -0500, Bruce Momjian wrote: > >> I can easily revert and come back, though the buildfarm is green now. > >> As far as testing, I can test that the cluster key unlocks the data > >> keys, but there is no current interface to the data keys. Ideally we > >> would test the full input/output path, but with no access to the output, > >> how can we test it? Also, as I stated, there are some shell script APIs > >> that can't easily be tested, e.g. AWS, Yubikey. I can continue to test > >> those manually. > > It seems to me that it is better to figure out that while the feature > is being developed, not after committing it so as there are > fully-functional tests at the same time the feature is committed. If > we don't have that in place, how can people know the amount of testing > that has been done for this feature? And how can anybody be sure that > nothing breaks if this area of the code gets changed? Manual testing > does not scale. For example, I have seen cases in the past where > implementing tests improved the whole state of a feature design > because it was possible to finish with a more flexible set of methods > for this feature. > > Based on the number of concerns raised by various people over the last > couple of days (including myself, one point being the refactoring of > the ciphers taken from pgcrypto that should have been in its own > commit), I agree that it would be better to revert this code for now.
OK, I will do so in the next few hours. My followup will be to: * register it for the commit-fest so it gets cfbot and other visibility * modify pgcrypto to use the new AES API (the SHA512 call no longer exists) * develop TAP tests, though as I mentioned, they will be odd -- Bruce Momjian <[email protected]> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
