Return to Answer

You can do using CTE:

WITH guest AS ( SELECT id FROM guest_list WHERE event_id=2985739029 LIMIT 1 ) SELECT * FROM event_user_detail WHERE guest_list_id IN (SELECT id FROM guest) 

CTE in older versions of postgresql runs like separate queries in one transactions and planned independently but doesn't send results from CTE to client.

You can read about them in the docs. Beware that this behaviour changed since 12 version of postgres and if you want to preserve old you should write it like:

WITH guest AS NOT MATERIALIZED ( SELECT id FROM guest_list WHERE event_id=2985739029 LIMIT 1 ) SELECT * FROM event_user_detail WHERE guest_list_id IN (SELECT id FROM guest) 

Also they are very useful to avoid deadlocks in updates:

WITH to_update AS ( SELECT * FROM my_table WHERE condition ORDER BY id ASC FOR UPDATE ) UPDATE my_table SET ... WHERE condition; 

This would make all rows lock in certain order which prevents deadlocks which possible with plain update queries (e.g. both queries need to modify ids 1 and 2, and with this CTE there cannot be that first lock 1 and wait 2 while second lock 2 and wait for 1).

You can do using CTE:

WITH guest AS ( SELECT id FROM guest_list WHERE event_id=2985739029 LIMIT 1 ) SELECT * FROM event_user_detail WHERE guest_list_id IN (SELECT id FROM guest) 

CTE in older versions of postgresql runs like separate queries in one transactions and planned independently but doesn't send results from CTE to client.

You can read about them in the docs. Beware that this behaviour changed since 12 version of postgres and if you want to preserve old you should write it like:

WITH guest AS MATERIALIZED ( SELECT id FROM guest_list WHERE event_id=2985739029 LIMIT 1 ) SELECT * FROM event_user_detail WHERE guest_list_id IN (SELECT id FROM guest) 

Also they are very useful to avoid deadlocks in updates:

WITH to_update AS ( SELECT * FROM my_table WHERE condition ORDER BY id ASC FOR UPDATE ) UPDATE my_table SET ... WHERE condition; 

This would make all rows lock in certain order which prevents deadlocks which possible with plain update queries (e.g. both queries need to modify ids 1 and 2, and with this CTE there cannot be that first lock 1 and wait 2 while second lock 2 and wait for 1).

You can do using CTE:

WITH guest AS ( SELECT id FROM guest_list WHERE event_id=2985739029 LIMIT 1 ) SELECT * FROM event_user_detail WHERE guest_list_id IN (SELECT id FROM guest) 

CTE in older versions of postgresql runs like separate queries in one transactions and planned independently but doesn't send results from CTE to client.

You can read about them in the docs. Beware that this behaviour changed since 12 version of postgres and if you want to preserve old you should write it like:

WITH guest AS NOT MATERIALIZED ( SELECT id FROM guest_list WHERE event_id=2985739029 LIMIT 1 ) SELECT * FROM event_user_detail WHERE guest_list_id IN (SELECT id FROM guest) 

Also they are very useful to avoid deadlocks in updates:

WITH to_update AS (SELECT * FROM my_table WHERE condition ORDER BY id ASC FOR UPDATE) UPDATE table SET ... WHERE condition; 

This would make all rows lock in certain order which prevents deadlocks which possible with update queries (e.g. both queries need to modify ids 1 and 2, and with this CTE there cannot be that first lock 1 and wait 2 while second lock 2 and wait for 1).

You can do using CTE:

WITH guest AS ( SELECT id FROM guest_list WHERE event_id=2985739029 LIMIT 1 ) SELECT * FROM event_user_detail WHERE guest_list_id IN (SELECT id FROM guest) 

CTE in older versions of postgresql runs like separate queries in one transactions and planned independently but doesn't send results from CTE to client.

You can read about them in the docs. Beware that this behaviour changed since 12 version of postgres and if you want to preserve old you should write it like:

WITH guest AS NOT MATERIALIZED ( SELECT id FROM guest_list WHERE event_id=2985739029 LIMIT 1 ) SELECT * FROM event_user_detail WHERE guest_list_id IN (SELECT id FROM guest) 

Also they are very useful to avoid deadlocks in updates:

WITH to_update AS ( SELECT * FROM my_table WHERE condition  ORDER BY id ASC FOR UPDATE  ) UPDATE my_table SET ... WHERE condition; 

This would make all rows lock in certain order which prevents deadlocks which possible with plain update queries (e.g. both queries need to modify ids 1 and 2, and with this CTE there cannot be that first lock 1 and wait 2 while second lock 2 and wait for 1).

You can do using CTE:

WITH guest AS ( SELECT id FROM guest_list WHERE event_id=2985739029 LIMIT 1 ) SELECT * FROM event_user_detail WHERE guest_list_id IN (SELECT id FROM guest) 

CTE in older versions of postgresql runs like separate queries in one transactions and planned independently but doesn't send results from CTE to client.

You can read about them in the docs. Beware that this behaviour changed since 12 version of postgres and if you want to preserve old you should write it like:

WITH guest AS NOT MATERIALIZED ( SELECT id FROM guest_list WHERE event_id=2985739029 LIMIT 1 ) SELECT * FROM event_user_detail WHERE guest_list_id IN (SELECT id FROM guest) 

You can do using CTE:

WITH guest AS ( SELECT id FROM guest_list WHERE event_id=2985739029 LIMIT 1 ) SELECT * FROM event_user_detail WHERE guest_list_id IN (SELECT id FROM guest) 

CTE in older versions of postgresql runs like separate queries in one transactions and planned independently but doesn't send results from CTE to client.

You can read about them in the docs. Beware that this behaviour changed since 12 version of postgres and if you want to preserve old you should write it like:

WITH guest AS NOT MATERIALIZED ( SELECT id FROM guest_list WHERE event_id=2985739029 LIMIT 1 ) SELECT * FROM event_user_detail WHERE guest_list_id IN (SELECT id FROM guest) 

Also they are very useful to avoid deadlocks in updates:

WITH to_update AS (SELECT * FROM my_table WHERE condition ORDER BY id ASC FOR UPDATE) UPDATE table SET ... WHERE condition; 

This would make all rows lock in certain order which prevents deadlocks which possible with update queries (e.g. both queries need to modify ids 1 and 2, and with this CTE there cannot be that first lock 1 and wait 2 while second lock 2 and wait for 1).