My Favorite Postgresql 18 Feature: Virtual Generated Columns

Posted4 months agoActive4 months ago

fforflo

54 points

9 comments

tselai.comTechstory

calmpositive

Debate

40/100

PostgresqlDatabase FeaturesSQL

Key topics

Postgresql

Database Features

SQL

The article discusses the new virtual generated columns feature in PostgreSQL 18, and the discussion revolves around its usefulness and comparisons to existing features and alternatives.

Snapshot generated from the HN discussion

Discussion Activity

Light discussion

First comment

Peak period

6-8h

Avg / period

1.8

Key moments

01Story posted
Sep 11, 2025 at 1:47 PM EDT
4 months ago
Step 01
02First comment
Sep 11, 2025 at 6:51 PM EDT
5h after posting
Step 02
03Peak activity
4 comments in 6-8h
Hottest window of the conversation
Step 03
04Latest activity
Sep 12, 2025 at 9:25 PM EDT
4 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (9 comments)

Showing 9 comments

saltcured

4 months ago

2 replies

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.

mdaniel

4 months ago

1 reply

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

saltcured

4 months ago

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.

sharlos201068

4 months ago

That's still not a column and isn't included with things like select *

_el1s7

4 months ago

1 reply

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...

combatentropy

4 months ago

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

sgarland

4 months ago

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!

garyclarke27

4 months ago

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.

icedchai

4 months ago

In the past, I've used views to add "virtual columns" where I didn't want to hard code them into the application.

View full discussion on Hacker News

ID: 45214209Type: storyLast synced: 11/20/2025, 4:50:34 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN