Re: "grant usage on schema" confers the ability to execute all user-defined functions in that schema, with needing to grant "execute"

On Fri, Feb 11, 2022 at 09:07:16PM -0800, Adrian Klaver wrote: > On 2/11/22 17:24, Bryn Llewellyn wrote: > > > > /b...@yugabyte.com  wrote:/ > > > I s'pose that I can interpret this output in the light of the "miriam" > > example by guessing than an empty LHS means "publi

Re: Microsoft Report Builder

I use Valentina Studio for some tasks. https://www.valentina-db.com/ru/valentina-studio-overview -- Regards, Dmitry! сб, 12 февр. 2022 г. в 08:23, Kim Foltz : > I am trying to configure Microsoft Report Builder to run against a > mainframe PostgreSQL database. The ODBC connection tests as good a

Re: "grant usage on schema" confers the ability to execute all user-defined functions in that schema, with needing to grant "execute"

On 2/11/22 17:24, Bryn Llewellyn wrote: /b...@yugabyte.com  wrote:/ I s'pose that I can interpret this output in the light of the "miriam" example by guessing than an empty LHS means "public" and that the initial "X" means "execute". It looks like what follows the sl

Re: Microsoft Report Builder

On 2/11/22 22:22, Kim Foltz wrote: I am trying to configure Microsoft Report Builder to run against a mainframe PostgreSQL database. The ODBC connection tests as good and manually entered SQL Select statements properly return data. The problem is the Query Designer in the software doesn't sup

Microsoft Report Builder

I am trying to configure Microsoft Report Builder to run against a mainframe PostgreSQL database. The ODBC connection tests as good and manually entered SQL Select statements properly return data. The problem is the Query Designer in the software d

Re: "grant usage on schema" confers the ability to execute all user-defined functions in that schema, with needing to grant "execute"

>> b...@yugabyte.com wrote: >> >> Which catalog relations are sufficient to support a query that lists out, >> for example, every user-defined function and procedure with its (at least >> first-level) grantees? > > adrian.kla...@aklaver.com wrote: > > Tip if you do: > > psql -d test -U postgr

Re: Can we go beyond the standard to make Postgres radically better?

On 10/02/2022 18:22, Peter J. Holzer wrote: On 2022-02-09 21:14:39 -0800, Guyren Howe wrote: Postgres has since the outset gone beyond the SQL standard in many ways : types, inheritance, programmability, generality are all well beyond what SQL used to mandate and still well beyond the current st

Re: "grant usage on schema" confers the ability to execute all user-defined functions in that schema, with needing to grant "execute"

On 2/11/22 15:48, Adrian Klaver wrote: On 2/11/22 15:14, Bryn Llewellyn wrote: /david.g.johns...@gmail.com wrote:/ Tip if you do: psql -d test -U postgres -h localhost -E the -E will get you the queries for the \ meta-commands. So: \df+ tag_changese

Re: "grant usage on schema" confers the ability to execute all user-defined functions in that schema, with needing to grant "execute"

On 2/11/22 15:14, Bryn Llewellyn wrote: /david.g.johns...@gmail.com wrote:/ I looked at Chapter 52, "System Catalogs" at https://www.postgresql.org/docs/current/catalogs.html . It lists 97 relations.

Re: "grant usage on schema" confers the ability to execute all user-defined functions in that schema, with needing to grant "execute"

> david.g.johns...@gmail.com wrote: > >> t...@sss.pgh.pa.us wrote: >> >> (I wonder if it'd be practical or useful to emit a warning when granting >> permissions on an object that already has a grant of >> the same permissions to PUBLIC. That would at least cue people who don't >> understand ab

Re: "grant usage on schema" confers the ability to execute all user-defined functions in that schema, with needing to grant "execute"

On Fri, Feb 11, 2022 at 3:05 PM Tom Lane wrote: > (I wonder if it'd be practical or useful to emit a warning when > granting permissions on an object that already has a grant of > the same permissions to PUBLIC. That would at least cue people > who don't understand about this behavior that they

Re: "grant usage on schema" confers the ability to execute all user-defined functions in that schema, with needing to grant "execute"

On Fri, Feb 11, 2022 at 2:44 PM Bryn Llewellyn wrote: > > p.s., What's "WADaD", David. Internet search doesn't find me the > translation except for, maybe, the Muslim name "Wadad" meaning "Love, > friendship. > > Working as designed, and documented.

Re: "grant usage on schema" confers the ability to execute all user-defined functions in that schema, with needing to grant "execute"

Bryn Llewellyn writes: > I confess that I'm surprised by the choice of the default behavior. It seems > to be at odds with the principle of least privilege that insists that you > actively opt in to any relevant privilege. I'd be the first to agree that this behavior sacrifices security princi

Re: "grant usage on schema" confers the ability to execute all user-defined functions in that schema, with needing to grant "execute"

> david.g.johns...@gmail.com wrote: > >> b...@yugabyte.com wrote: >> >> grant usage on schema s to z; >> revoke execute on function s.f() from z; -- Yes, really! >> >> *This surprises me* >> >> The PG doc on, in the "5.7. Privileges" section at >> https://www.postgresql.org/docs/current/ddl-pr

Re: "grant usage on schema" confers the ability to execute all user-defined functions in that schema, with needing to grant "execute"

On Fri, Feb 11, 2022 at 1:46 PM Bryn Llewellyn wrote: > > > *grant usage on schema s to z;revoke execute on function s.f() from z; -- > Yes, really!* > > **This surprises me** > > The PG doc on, in the "5.7. Privileges" section at > https://www.postgresql.org/docs/current/ddl-priv.html (under "US

Re: "grant usage on schema" confers the ability to execute all user-defined functions in that schema, with needing to grant "execute"

Bryn Llewellyn writes: > If user "x" owns function "s.f()", and if you want user "z" to be able to > execute it, then this alone is insufficient: > grant execute on function s.f() to z; > The attempt by "z" to execute "s.f()" this draws the 42501 error, "permission > denied for schema s". But

Re: Can we go beyond the standard to make Postgres radically better?

On 2022-02-10 16:13:33 -0500, Bruce Momjian wrote: > On Thu, Feb 10, 2022 at 06:25:45PM +0100, Peter J. Holzer wrote: > > On 2022-02-10 18:22:29 +0100, Peter J. Holzer wrote: > > > On 2022-02-09 21:14:39 -0800, Guyren Howe wrote: > > > > • SELECT * - b.a_id from a natural join b > > > > > > My u

"grant usage on schema" confers the ability to execute all user-defined functions in that schema, with needing to grant "execute"

*Summary* If user "x" owns function "s.f()", and if you want user "z" to be able to execute it, then this alone is insufficient: grant execute on function s.f() to z; The attempt by "z" to execute "s.f()" this draws the 42501 error, "permission denied for schema s". But this _is_ sufficient:

Re: Can we go beyond the standard to make Postgres radically better?

On Fri, Feb 11, 2022 at 3:16 AM Ron wrote: > On 2/10/22 10:33 PM, Raymond Brinzer wrote: > > The answer is obvious to every grey beard: SQL was developed from SEQUEL, > Structured *ENGLISH* Query Language at a company that loved English-style > programming languages. > > "SELECT column FROM myt

Re: Can we go beyond the standard to make Postgres radically better?

On 2/11/22 09:12, Mladen Gogala wrote: On 2/11/22 09:48, Benedict Holland wrote: So to summarize, people are bad programmers who refuse to learn SQL So SQL is the problem? Common. You cannot bring that to a postgres list serve. Look. It's not perfect. It's a pain. It is hard to generate queri

Re: Can we go beyond the standard to make Postgres radically better?

On 2/11/22 09:48, Benedict Holland wrote: So to summarize, people are bad programmers who refuse to learn SQL So SQL is the problem? Common. You cannot bring that to a postgres list serve. Look. It's not perfect. It's a pain. It is hard to generate queries (oh my God why are you doing this?)

table not found on publisher

Hello All, It is a bit specific logical replication setup where we try to replicate a partitioned table (pg14.1) to a non-partitioned one (pg11.14) After establishing everything the subscriber fails on the initial copy with ERROR: table "public.tab01" not found on publisher If the subscription i

Re: Can we go beyond the standard to make Postgres radically better?

So to summarize, people are bad programmers who refuse to learn SQL So SQL is the problem? Common. You cannot bring that to a postgres list serve. Look. It's not perfect. It's a pain. It is hard to generate queries (oh my God why are you doing this?) and it's hard to work with. You are describing

Re: Can we go beyond the standard to make Postgres radically better?

On 2/10/22 23:56, Guyren Howe wrote: On Feb 10, 2022, at 17:06 , Mladen Gogala wrote: But SQL is a terrible, no good, very bad language. I cannot accept such a religious persecution of SQL without a detailed explanation. I feel like anyone who is defending SQL here isn’t aware of how

Re: Can we go beyond the standard to make Postgres radically better?

> Give me a couple million bucks, and I’ll hire some of the Postgres devs to build a new database. > We could crib some of the low-level code from Postgres, but everything above the low level would need to be rewritten. You can check the EdgeDB experiments:https://www.edgedb.com/ *"What is Edg

Re: Can we go beyond the standard to make Postgres radically better?

Peter J. Holzer wrote: > > My use case for such a feature are tables which contain one column (or a > > small number of columns) which you usually don't want to select: A bytea > > column or a very wide text column. In a program I don't mind (in fact I > > prefer) listing all the columns e

Re: Can we go beyond the standard to make Postgres radically better?

On 2/10/22 10:33 PM, Raymond Brinzer wrote: [snip] Here's one that I think is simple:  why would we want a language where the clauses must come in a particular order?  `FROM mytable SELECT column` is as clear an expression as `SELECT column FROM mytable`, and probably better, in that it starts