6 comments

[ 2.9 ms ] story [ 26.5 ms ] thread
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.
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!

In the past, I've used views to add "virtual columns" where I didn't want to hard code them into the application.
Stored generated columns would be much more useful if they could reference other rows and tables, they are limited to only the current row. Automatic incremental view maintenance would also solve this problem, but is unfortunately still a glaring omission in Postgres capabilities.
I don't really find these kind of features necessary.

You can, and probably should, do these things in your application code. I mean, it's not really that hard to make a string lowercase, you don't need to define a "virtual colum" for that...

You're right, it's not that hard. But why would you rather do it there?