Aside from the SQL syntax, what is the difference between this and the longstanding virtual column feature, where you can define a function that takes the table's record type as input and return a scalar? PostgreSQL already let you use table.funcname as a virtual column, as I recall.
It's possible the following argument is what you meant by "from the SQL syntax," and if so apologies for the noise
At least one demonstrable difference I can see between your recollection and this feature is that the column name being part of the DDL pushes the logic down into the DDL, versus every client having to carry that magic expression around with them. I think it's likely the age-old application-logic-client-side versus stored-proc camps
db=# select id, cast(length(name) AS text)||'0' as silly from my_table
as compared to <<select id, silly from my_table>> for the consumer
The virtual column feature I remember is halfway in between. It is not part of the DDL nor reported table schema, so the developer needs to know about it.
But if a function called silly with input type my_table existed, you could still do your second query. It has syntactic sugar for making a bare function name implicitly invoke on the current row record.
I can't remember if that sugar could also be used in an expression index. I never really used this syntactic feature, as I thought being more explicit with function calls would be better coding style.
In the past, I've used views to add "virtual columns" where I didn't want to hard code them into the application.
Welp, that’s it. That was the last thing MySQL had that Postgres didn’t (modulo clustering index, which OrioleDB does, soooo…).
Can’t wait!
Aside from the SQL syntax, what is the difference between this and the longstanding virtual column feature, where you can define a function that takes the table's record type as input and return a scalar? PostgreSQL already let you use table.funcname as a virtual column, as I recall.
It's possible the following argument is what you meant by "from the SQL syntax," and if so apologies for the noise
At least one demonstrable difference I can see between your recollection and this feature is that the column name being part of the DDL pushes the logic down into the DDL, versus every client having to carry that magic expression around with them. I think it's likely the age-old application-logic-client-side versus stored-proc camps
as compared to <<select id, silly from my_table>> for the consumerThe virtual column feature I remember is halfway in between. It is not part of the DDL nor reported table schema, so the developer needs to know about it.
But if a function called silly with input type my_table existed, you could still do your second query. It has syntactic sugar for making a bare function name implicitly invoke on the current row record.
I can't remember if that sugar could also be used in an expression index. I never really used this syntactic feature, as I thought being more explicit with function calls would be better coding style.
That's still not a column and isn't included with things like select *