Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?

2023-03-22 Thread Adrian Klaver
On 3/22/23 12:09, Bryn Llewellyn wrote: laurenz.a...@cybertec.at wrote: ...I understand that you ask questions to gain deeper understanding. b...@yugabyte.com wrote: ...I had never come across use cases where [scrollability] was be

Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?

2023-03-22 Thread Laurenz Albe
On Wed, 2023-03-22 at 12:09 -0700, Bryn Llewellyn wrote: > > laurenz.a...@cybertec.at wrote: > > I recently used cursor scrollability, so I can show you a use case: > > > > github.com/cybertec-postgresql/db_migrator/blob/master/db_migrator--1.0.0.sql#L49 > > However, source code famously reveals o

Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?

2023-03-22 Thread Bryn Llewellyn
> laurenz.a...@cybertec.at wrote: > > ...I understand that you ask questions to gain deeper understanding. > >> b...@yugabyte.com wrote: >> >> ...I had never come across use cases where [scrollability] was beneficial. I >> wanted, therefore, to hear about some. I thought that insights here woul

Re: For temporary tables; truncate vs on commit delete all

2023-03-22 Thread Laurenz Albe
On Wed, 2023-03-22 at 11:59 +, Jim Vanns wrote: > Does anyone have any idea which is generally better (by better I mean > most efficient/quickest!) in this simple scenario? I have a temporary > table which I wish to retain for the duration of a long-running > session. However, for each transact

For temporary tables; truncate vs on commit delete all

2023-03-22 Thread Jim Vanns
Does anyone have any idea which is generally better (by better I mean most efficient/quickest!) in this simple scenario? I have a temporary table which I wish to retain for the duration of a long-running session. However, for each transaction it must be purged. So, is it better to; a) Always CREAT

Re: Logical replication fails when adding multiple replicas

2023-03-22 Thread Will Roper
Thanks for the response Hou, I've had a look and when the tablesync workers are spinning up there are some errors of the form: "2023-03-17 18:37:06.900 UTC [4071] LOG: logical replication table synchronization worker for subscription ""polling_stations_0561a02f66363d911"", table ""uk_geo_utils_o