docs: limitation when selecting related object that was modified by n after insert trigger

[laurenceisla]

A user noted that the after insert query didn't reflect when selecting the modified related table. So I think it would be nice to add this limitation here and inform that a better alternative would be available in the future.

The details are explained in the note I added to the docs. If the explanation is too verbose, then I'll summarize it further.

Info that backs this up:

• "The sub-statements in WITH are executed concurrently with each other and with the main query" ( PostgreSQL docs)
• This PostgreSQL Q/A: https://www.postgresql.org/message-id/CAKFQuwYsCPJwNwSjvsP-FVEiojCgLoWpeir%3Dczuk311MKTs69w%40mail.gmail.com

[wolfgangwalther]

I did not look deeper at the other stuff, but I would not put such a sentence in the docs.

Rather:

Suggested change

	In the future we'll implement the insertions of tables and embedded resources at the same time.
	For now, an alternative is to use :ref:`table_functions` instead.
	An alternative is to use :ref:`table_functions` instead.

After all, you never know what the future holds ;)

[laurenceisla]

Wanted to give an idea of "working on it", but yeah, I see that it may be too optimistic.

[wolfgangwalther]

One more thought of this: Would you consider this a bug? The wording you took sounds like it. As such, I would not even add a note at all, but just create an issue in the bugtracker? The issue could then mention the workaround. We should not document bugs, I guess..

[laurenceisla]

I didn't consider this as a bug at first because of our design choice in executing the entire mutation/selection in a single query (I was wrong there, I said "single transaction" instead of "single query"). It's a PostgreSQL expected behavior so the mention of a heads-up seemed OK to me, in case someone encountered this.

But I get how this could be considered a bug if the design is prone to change. I'll open an issue regardless, with a full example to see if it's worth documenting or just track as bug.

[laurenceisla]

Added the issue #3286

Also, NVM the workaround, a more complicated query (with json aggregates) needs to be done in the function.