Horton

Re: BUG #18097: Immutable expression not allowed in generated at

Aleksander Alekseev <aleksander@timescale.com>

View thread
From: Aleksander Alekseev <aleksander@timescale.com>
To: pgsql-hackers@lists.postgresql.org
Cc: Tom Lane <tgl@sss.pgh.pa.us>, James Keener <jim@jimkeener.com>
Date: 2023-11-15T11:44:09Z
Lists: pgsql-bugs, pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Ensure we preprocess expressions before checking their volatility.

Hi,

> > Oh no! We encountered one of the most difficult problems in computer
> > science [1].
>
> Indeed :-(.  Looking at it again this morning, I'm thinking of
> using "contain_mutable_functions_after_planning" --- what do you
> think of that?

It's better but creates an impression that the actual planning will be
involved. According to the comments for expression_planner():

```
 * Currently, we disallow sublinks in standalone expressions, so there's no
 * real "planning" involved here.  (That might not always be true though.)
```

I'm not very well familiar with the part of code responsible for
planning, but I find this inconsistency confusing.

Since the code is written for people to be read and is read more often
than written personally I believe that longer and more descriptive
names are better. Something like
contain_mutable_functions_after_planner_transformations(). This being
said, in practice one should read the comments to learn about corner
cases, pre- and postconditions anyway, so maybe it's not that a big
deal. I think of contain_mutable_functions_after_transformations() as
a good compromise between the length and descriptiveness.

-- 
Best regards,
Aleksander Alekseev