WL#411 actually is about generated non-always-virtual columns
I’ve been editing a task description in our worklog:
WL#411 Computed virtual columns as MS SQL server has.
The quirky thing about the description, nowadays, is that the columns aren’t necessarily computed, aren’t necessarily virtual, and — if anybody follows the general policy that we should be like the standard — won’t much resemble SQL Server. So it’s not a very good name, eh?
The topical thing about the description is that it differs from a bugs.mysql.com feature request
Bug#46491 Patch: Virtual columns (WL#411). This is another name that could be questioned, since in reality the patch doesn’t look like WL#411. (And before I edited the specification, the resemblance was no better.) Yet it’s perfectly acceptable, as evidenced by the fact that a non-MySQL DBMS accepted it.
What we have, and probably always will have in MySQL, is a question about whether a patch should come in because it’s done (as illustrated by the frequent plaint “why is my patch taking years to get in?”), or whether the specification should come first and then the architecture review, with implementation last. I’ll avoid predicting how this one will come out.
August 4th, 2009 at 4:08 am
How will OLD/NEW values for these virtual columns work? Will a trigger be able to override a value generated at storage time for persistent values?
Should non-deterministic generation clauses even be allowed?
August 4th, 2009 at 4:17 pm
WL#411 says that OLD/NEW values won’t work.
And it says BEFORE triggers happen before generation, so they couldn’t “override”.
And maybe non-deterministic generation should be illegal, but we have a hard time catching them.