Re: New default role- 'pg_read_all_data'

2020-08-27 Thread Steven Pousty
On Thu, Aug 27, 2020 at 5:30 PM Stephen Frost wrote: > Greetings, > > There's no shortage of requests and responses regarding how to have a > 'read all of the data' role in PG, with various hacks involving "GRANT > ALL" and "ALTER DEFAULT PRIVILEGES" to "solve" this, neither of which > really

Re: Poll: are people okay with function/operator table redesign?

2020-04-15 Thread Steven Pousty
Is there a way to get a heavier line between each function? It would be helpful to have a clearer demarcation of what belongs to each function. On Wed, Apr 15, 2020 at 9:04 AM Robert Haas wrote: > On Wed, Apr 15, 2020 at 11:54 AM Pavel Stehule > wrote: > > st 15. 4. 2020 v 17:43 odesílatel

Re: jsonb_set() strictness considered harmful to data

2019-10-21 Thread Steven Pousty
On Sun, Oct 20, 2019 at 4:31 PM raf wrote: > Steven Pousty wrote: > > > I would think though that raising an exception is better than a > > default behavior which deletes data. > > I can't help but feel the need to make the point that > the function is not de

Re: jsonb_set() strictness considered harmful to data

2019-10-20 Thread Steven Pousty
I would think though that raising an exception is better than a default behavior which deletes data. As an app dev I am quite used to all sorts of "APIs" throwing exceptions and have learned to deal with them. This is my way of saying that raising an exception is an improvement over the current

Re: JSONPATH documentation

2019-09-23 Thread Steven Pousty
at 11:07 AM Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Mon, Sep 23, 2019 at 7:52 PM Steven Pousty > wrote: > > JSON Containment, JSONPath, and Transforms are means to work with JSONB > but not the actual datatype itself. Doc should be split into > > 1)

Re: JSONPATH documentation

2019-09-23 Thread Steven Pousty
JSON Containment, JSONPath, and Transforms are means to work with JSONB but not the actual datatype itself. Doc should be split into 1) Data type - how do declare, indexing, considerations when using it... 2) Ways to work with the data type - functions, containment, JSONPath... These can be

Re: SQL/JSON path issues/questions

2019-07-23 Thread Steven Pousty
Ok I have the toolset. Where do I find the PR for the doc on this work. I only feel qualified to review the doc. Thanks Steve On Sat, Jul 20, 2019 at 11:48 AM Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > Hi Steven, > > On Fri, Jul 19, 2019 at 9:53 PM Steven Pousty

Re: SQL/JSON path issues/questions

2019-07-20 Thread Steven Pousty
Thanks so much, hope to get to it over this weekend. On Sat, Jul 20, 2019, 11:48 AM Alexander Korotkov wrote: > Hi Steven, > > On Fri, Jul 19, 2019 at 9:53 PM Steven Pousty > wrote: > > I would like to help review this documentation. Can you please point me > in the right

Re: SQL/JSON path issues/questions

2019-07-19 Thread Steven Pousty
I would like to help review this documentation. Can you please point me in the right direction? Thanks Steve On Fri, Jul 19, 2019 at 2:02 AM Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Thu, Jul 18, 2019 at 5:08 PM Thom Brown wrote: > > On Tue, 16 Jul 2019 at 19:44, Alexander

Re: Switching PL/Python to Python 3 by default in PostgreSQL 12

2019-07-07 Thread Steven Pousty
comfortable letting this just pass without mention. All that aside, I think allowing the admin set the default version of plpythonu to be an excellent idea. Thanks Steve On Sun, Jul 7, 2019, 8:26 AM Tom Lane wrote: > Peter Eisentraut writes: > > On 2019-07-07 00:34, Steven Pousty wrote:

Re: Switching PL/Python to Python 3 by default in PostgreSQL 12

2019-07-06 Thread Steven Pousty
Why would it be a 13 or later issue? I am specifically talking about changing the default. On Sat, Jul 6, 2019, 6:28 PM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2019-07-06 21:02, Steven Pousty wrote: > > /" The default will probably be changed to P

Switching PL/Python to Python 3 by default in PostgreSQL 12

2019-07-06 Thread Steven Pousty
Greetings: I am not sure if this has been brought up before but Python 2 is EOL on Jan 1 2020. After that time there will not be any security fixes or patches. https://python3statement.org/ According to our most recent official documentation: