Re: SQL Property Graph Queries (SQL/PGQ)
| От | Ashutosh Bapat |
|---|---|
| Тема | Re: SQL Property Graph Queries (SQL/PGQ) |
| Дата | |
| Msg-id | CAExHW5sitKZSSKZVj2kAB8qtdtg4v-R4fgOgsu44tONsMosL9Q@mail.gmail.com обсуждение |
| Ответ на | Re: SQL Property Graph Queries (SQL/PGQ) (Peter Eisentraut <peter@eisentraut.org>) |
| Ответы |
Re: SQL Property Graph Queries (SQL/PGQ)
Re: SQL Property Graph Queries (SQL/PGQ) |
| Список | pgsql-hackers |
On Wed, Mar 18, 2026 at 12:59 PM Peter Eisentraut <peter@eisentraut.org> wrote: > > On 17.03.26 14:57, Peter Eisentraut wrote: > > On 16.03.26 16:54, Ashutosh Bapat wrote: > >> The patch looks fine to me. While reviewing it, I noticed that the > >> function has an extra loop to count the number of variables. I don't > >> think it's needed. The count can be obtained from the list length. In > >> the attached patch, I have removed that loop. Am I missing something? > >> > >> 0001 is your patch > >> 0002 removes the loop + some cosmetic changes > > > > committed > > There are still some pg_upgrade-related failures on the buildfarm, but > AFAICT these are not specifically from this feature but more from the > test design of the PG_TEST_EXTRA="regress_dump_restore" test. It looks > like we need to drop all users at the end of > src/test/regress/sql/graph_table_rls.sql to make this work. > PFA the patch. I tried using --no-owner with pg_restore and pg_dump but that doesn't work since it doesn't exclude policies. I had to add "reassign owner to" so that we could retain as many objects as possible. Also had to drop the policies which are applicable to users being dropped. Reassign doesn't work on policies, ofc. I remember thinking about using pg_dumpall instead of pg_dump in 002_pg_upgrade, but IIRC, we faced some issues doing so. Didn't try that this time. If that works, we may not need to drop users. But I am not sure if the test coverage we will get for dump/restore is worth it. -- Best Wishes, Ashutosh Bapat
Вложения
В списке pgsql-hackers по дате отправления: