Re: Allowing additional commas between columns, and at the end of the SELECT clause

Hi, As a developer, I love this feature. But as a developer of an universal TDOP SQL parser[1], this can be a pain. Please request it to the standard. Regards, Étienne [1]: https://gitlab.com/dalibo/transqlate

Re: Security lessons from liblzma - libsystemd

Hi, > There are many more interesting and scary libraries in the dependency > tree of "postgres", so just picking off one right now doesn't really > accomplish anything.  The next release of libsystemd will drop all > the compression libraries as hard dependencies, so the issue in that > sense is

REASSIGN pg_auth_members

antor role ? Should we fix REASSIGN to change grantor in pg_auth_members ? Regards, Étienne BERSAC Dalibo my-reassign.sql Description: application/sql

Re: REVOKE FROM warning on grantor

Hi, > ldap2pg really ought to issue REVOKE x FROM y GRANTED BY z. Thanks for this. I missed this notation and it is exactly what I need. You could consider this subject as closed. Thanks for your time and explanation. Regards, Étienne

Re: REVOKE FROM warning on grantor

Hi, > https://dev.mysql.com/doc/refman/8.0/en/revoke.html documents an "IF > EXISTS" option whose documentation reads, in relevant part, > "Otherwise, REVOKE executes normally; if the user does not exist, the > statement raises an error." > > https://community.snowflake.com/s/article/Access-Con

Re: REVOKE FROM warning on grantor

Hi Tom, Thanks for your anwser. > It does not say that that set must be nonempty.  Admittedly it's not > very clear from this one point.  However, if you look around in the > standard it seems clear that they expect no-op revokes to be no-ops > not errors. Postgres actually identifies memberhip

Re: REVOKE FROM warning on grantor

Hi David, > That should have read:  the granted permission does not exist Thanks, its clear. However, I'm hitting the warning when removing a role from a group. But the membership remains after the warning. In this case, I expect an error. I'll try to patch the behaviour to ensure an error if t

Re: REVOKE FROM warning on grantor

Hi David, Thanks for your answer. > The choice of warning is made because after the command ends the > grantmin question does not exist.  The revoke was a no-op and the > final state is as the user intended.  Sorry, can you explain me what's the grantmin question is ? Regards, Étienne

REVOKE FROM warning on grantor

Hi, Since ldap2pg 6, I'm working on running by default as non-super role with CREATEDB. Robert Haas made this a viable solution as of Postgres 16. I got a case where ldap2pg tries to remove a role from a group. But ldap2pg user is not the grantor of this membership. This triggers a warning: $ RE

Re: RFC: Logging plan of the running query

> Hi, > > If we use client log message, that message is shown on the target > process whose pid is specified by the parameter of > pg_log_query_plan(): > >    (pid:1000)=# select pg_sleep(60); >    (pid:1001)=# select pg_log_query_plan(1000); >    (pid:1000)=# LOG:  query plan running on backen

Re: run pgindent on a regular basis / scripted manner

Hello, > Yes, there's a lot to look out for, and you're a damn sight better at > it > than I am. But we should try to automate the things that can be > automated, even if that leaves many tasks that can't be. I have three > things in my pre-commit hook: a check for catalog updates, a check > fo

Re: RFC: Logging plan of the running query

Hi Torikoshia, > If so, we once tried to implement such function for getting memory > contexts. > However, this attempt didn't succeed because it could lead dead lock > situation[1]. Thanks for the pointer. Why not use client log message to allow client to get plan without locking backend mem

Re: RFC: Logging plan of the running query

_query_plan(pid, format) which output would be the same as EXPLAIN. Regards, Étienne BERSAC Dalibo

Re: logfmt and application_context

Hi, Le mercredi 27 septembre 2023 à 10:14 +0200, Daniel Gustafsson a écrit : > Being a common format in ingestion tools makes it interesting though, but I > wonder if those tools aren't alreday supporting CSV such that adding logfmt > won't move the compatibility markers much? Compared to CSV, lo

Re: logfmt and application_context

Hi Daniel, Thanks for the feedback. Le mardi 05 septembre 2023 à 11:35 +0200, Daniel Gustafsson a écrit : > > On 30 Aug 2023, at 14:36, Étienne BERSAC wrote: > > > ..what do you think of having logfmt output along json and CSV ? > > Less ideal is > that there is no of

logfmt and application_context

PostgreSQL and available in log_line_prefix ? Anyway, it's my first attempt at writing C code for PostgreSQL, with the help of Guillaume LELARGE and Jehan-Guillaume de RORTHAIS and it's a pleasure ! PostgreSQL C code is very readable. Thanks everyone for this ! Regards, Étienne BERSAC De