Re: [HACKERS] Row Level Security Documentation

On 26 September 2017 at 00:42, Stephen Frost <sfr...@snowman.net> wrote: > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: >> Attached is a proposed patch... > > I've taken a look through this and generally agree with it. Thanks for looking at this. > the bits

Re: [HACKERS] Row Level Security Documentation

On 5 August 2017 at 10:03, Fabien COELHO wrote: > Patch applies cleanly, make html ok, new table looks good to me. > So I started looking at this patch, but before even considering the new table proposed, I think there are multiple issues that need to be resolved with the

[HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On 14 September 2017 at 03:49, Noah Misch wrote: > On Wed, Sep 13, 2017 at 12:06:40PM -0400, Robert Haas wrote: >> OK, thanks. I still don't really like allowing this, but I can see >> that compatibility with other systems has some value here, and if >> nobody else is

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On 13 September 2017 at 14:51, Robert Haas wrote: > Coincidentally, I wrote a patch for this too, but mine goes back to > rejecting MINVALUE or MAXVALUE followed by anything else. > LGTM, if we decide to go this way. One minor review comment -- you missed an example code

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On 13 September 2017 at 10:05, Amit Langote wrote: > Coincidentally, I just wrote the patch for canonicalizing stored values, > instead of erroring out. Please see attached if that's what you were > thinking too. > Looks reasonable to me, if we decide to go this

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On 13 September 2017 at 14:53, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Sep 13, 2017 at 4:51 AM, Dean Rasheed <dean.a.rash...@gmail.com> > wrote: >> A drawback to doing this is that we lose compatibility with syntaxes >> supported by other databases

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

Robert Haas writes: > On Tue, Sep 12, 2017 at 9:58 AM, Alvaro Herrera > wrote: >> Did anything happen on this, or did we just forget it completely? > > I forgot it. :-( > > I really think we should fix this. Ah, sorry. This was for me to follow

Re: [HACKERS] dubious error message from partition.c

On 9 August 2017 at 13:03, Robert Haas wrote: > On Tue, Aug 8, 2017 at 11:34 PM, Tom Lane wrote: >> A small suggestion is that it'd be better to write it like "Specified >> upper bound \"%s\" precedes lower bound \"%s\"." I think "succeeds" has >> more

[HACKERS] Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b

On 8 August 2017 at 19:22, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Jul 21, 2017 at 4:24 AM, Dean Rasheed <dean.a.rash...@gmail.com> > wrote: >> Also drop the constraint prohibiting finite values after an unbounded >> column, and just document the fact

Re: [HACKERS] Minor comment update in partition.c

On 31 July 2017 at 12:53, Beena Emerson wrote: > The commit d363d42bb9a4399a0207bd3b371c966e22e06bd3 changed > RangeDatumContent *content to PartitionRangeDatumKind *kind but a > comment on function partition_rbound_cmp was left unedited and it > still mentions content1

Re: [HACKERS] Multi column range partition table

On 17 July 2017 at 17:37, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > On 17 July 2017 at 16:34, Robert Haas <robertmh...@gmail.com> wrote: >> Do you want to own this open item, then? >> > OK. > > I need to give the patch another read-through, and

Re: [HACKERS] Multi column range partition table

On 17 July 2017 at 16:34, Robert Haas <robertmh...@gmail.com> wrote: > On Sun, Jul 16, 2017 at 6:40 AM, Dean Rasheed <dean.a.rash...@gmail.com> > wrote: >> Technically, anything that can be done using INCLUSIVE/EXCLUSIVE can >> also be done using using MINVALUE/MA

Re: [HACKERS] Multi column range partition table

On 14 July 2017 at 06:12, Robert Haas wrote: > I agree that it's a big problem that (10, UNBOUNDED) > interpreted as a maximum value means first_column <= 10 and when > interpreted as a minimum value means first_column >= 10, because those > things aren't opposites of each

Re: [HACKERS] Multi column range partition table

On 12 July 2017 at 10:46, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Wed, Jul 12, 2017 at 12:54 AM, Dean Rasheed <dean.a.rash...@gmail.com> > wrote: >> On 11 July 2017 at 13:29, Ashutosh Bapat >>> The description in this paragraph seems to b

Re: [HACKERS] New partitioning - some feedback

On 12 July 2017 at 23:23, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > I also agree that there probably isn't much need for a list that > *only* includes partitions, but if someone comes up with a convincing > use case, then we could add another 2-letter command for that. >

Re: [HACKERS] New partitioning - some feedback

On 12 July 2017 at 15:58, Alvaro Herrera wrote: > Amit Langote wrote: >> On 2017/07/11 13:34, Alvaro Herrera wrote: >> > However, the "list tables" >> > command \dt should definitely IMO not list partitions. >> >> Do you mean never? Even if a modifier is specified? In

Re: [HACKERS] Multi column range partition table

On 11 July 2017 at 13:29, Ashutosh Bapat wrote: > + > + Also note that some element types, such as timestamp, > + have a notion of "infinity", which is just another value that can > + be stored. This is different from MINVALUE and > +

Re: [HACKERS] Multi column range partition table

On 6 July 2017 at 22:43, Joe Conway wrote: > I agree we should get this right the first time and I also agree with > Dean's proposal, so I guess I'm a +2 > On 7 July 2017 at 03:21, Amit Langote wrote: > +1 to releasing this syntax in PG 10. >

Re: [HACKERS] Multi column range partition table

On 7 July 2017 at 03:21, Amit Langote wrote: > The patch looks generally good, although I found and fixed some minor > issues (typos and such). Please find attached the updated patch. > Thanks for the review. Those changes all look good. I also see that I missed

Re: [HACKERS] Multi column range partition table

On 6 July 2017 at 21:04, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dean Rasheed <dean.a.rash...@gmail.com> writes: >> However, this is also an incompatible syntax change, and any attempt >> to support both the old and new syntaxes is likely to be messy, so we >

Re: [HACKERS] Multi column range partition table

On 5 July 2017 at 18:07, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > So if we were to go for maximum flexibility and compatibility with > Oracle, then perhaps what we would do is more like the original idea > of UNBOUNDED ABOVE/BELOW, except call them MINVALUE and MA

Re: [HACKERS] Multi column range partition table

On 5 July 2017 at 10:43, Amit Langote wrote: > 0001 is your patch to tidy up check_new_partition_bound() (must be > applied before 0002) > I pushed this first patch, simplifying check_new_partition_bound() for range partitions, since it seemed like a good

Re: [HACKERS] Multi column range partition table

On 5 July 2017 at 10:43, Amit Langote wrote: > In retrospect, that sounds like something that was implemented in the > earlier versions of the patch, whereby there was no ability to specify > UNBOUNDED on a per-column basis. So the syntax was: > > FROM { (x [,

Re: [HACKERS] Multi column range partition table

On 5 July 2017 at 10:43, Amit Langote wrote: >> So the more I think about this, the more I think that a cleaner design >> would be as follows: >> >> 1). Don't allow UNBOUNDED, except in the first column, where it can >> keep it's current meaning. >> >> 2). Allow

Re: [HACKERS] Multi column range partition table

On 3 July 2017 at 10:32, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/07/03 17:36, Dean Rasheed wrote: >> The bigger question is do we want this for PG10? If so, time is >> getting tight. My feeling is that we do, because otherwise we'd be >>

Re: [HACKERS] Multi column range partition table

On 3 July 2017 at 06:00, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/07/03 2:15, Dean Rasheed wrote: >> My first thought was UNBOUNDED ABOVE/BELOW, because that matches the >> terminology already in use of upper and lower bounds. > > I was star

Re: [HACKERS] Multi column range partition table

On 30 June 2017 at 10:04, Ashutosh Bapat wrote: > On Fri, Jun 30, 2017 at 1:36 PM, Amit Langote > wrote: >> >> Alright, I spent some time implementing a patch to allow specifying >> -infinity and +infinity in arbitrary ways. Of

Re: [HACKERS] Multi column range partition table

On 30 June 2017 at 09:06, Amit Langote wrote: > When testing the patch, I realized that the current code in > check_new_partition_bound() that checks for range partition overlap had a > latent bug that resulted in false positives for the new cases that the new >

Re: [HACKERS] Multi column range partition table

On 23 June 2017 at 08:01, Ashutosh Bapat wrote: > The way we have designed our syntax, we don't have a way to tell that > p3 comes after p2 and they have no gap between those. But I don't > think that's your question. What you are struggling with is a way to >

Re: [HACKERS] Rules on table partitions

On 20 June 2017 at 03:01, Amit Langote wrote: > Hmm, yes. The following exercise convinced me. > > create table r (a int) partition by range (a); > create table r1 partition of r for values from (1) to (10); > create rule "_RETURN" as on select to r1 do instead

Re: [HACKERS] Rules on table partitions

On 20 June 2017 at 03:01, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/06/19 20:19, Dean Rasheed wrote: >> Currently we allow rules to be defined on table partitions, but these >> rules only fire when the partition is accessed directly, not when it >>

[HACKERS] Rules on table partitions

Currently we allow rules to be defined on table partitions, but these rules only fire when the partition is accessed directly, not when it is accessed via the parent: CREATE TABLE t1(a int, b int) PARTITION BY RANGE(a); CREATE TABLE t1_p PARTITION OF t1 FOR VALUES FROM (1) TO (10); INSERT INTO t1

Re: [HACKERS] PG10 Partitioned tables and relation_is_updatable()

On 13 June 2017 at 05:50, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Tue, Jun 13, 2017 at 12:03 AM, Dean Rasheed <dean.a.rash...@gmail.com> > wrote: >> Barring objections, I'll push my original patch and work up patches >> for the

Re: [HACKERS] PG10 Partitioned tables and relation_is_updatable()

On 13 June 2017 at 05:50, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Tue, Jun 13, 2017 at 12:03 AM, Dean Rasheed <dean.a.rash...@gmail.com> > wrote: >> My initial thought, looking at the patch, is that it might be better >> to have all the macros i

Re: [HACKERS] PG10 Partitioned tables and relation_is_updatable()

On 12 June 2017 at 17:51, Joe Conway wrote: > On 06/12/2017 07:40 AM, Joe Conway wrote: >> On 06/12/2017 01:49 AM, Amit Langote wrote: >>> As he mentioned in his reply, Ashutosh's proposal to abstract away the >>> relkind checks is interesting in this regard. >>> >> I have not

Re: [HACKERS] Make ANALYZE more selective about what is a "most common value"?

On 11 June 2017 at 20:19, Tom Lane wrote: >> The standard way of doing this is to calculate the "standard error" of >> the sample proportion - see, for example [3], [4]: >> SE = sqrt(p*(1-p)/n) >> Note, however, that this formula assumes that the sample size n is >> small

Re: [HACKERS] PG10 Partitioned tables and relation_is_updatable()

On 11 June 2017 at 16:59, Joe Conway wrote: > On 06/11/2017 08:55 AM, Joe Conway wrote: >> Yeah, I noticed the same while working on the RLS related patch. I did >> not see anything else in rewriteHandler.c but it is probably worth >> looking wider for other omissions. > > So

Re: [HACKERS] Make ANALYZE more selective about what is a "most common value"?

On 05/06/17 09:30, Tom Lane wrote: > First, I think we need a larger hard floor on the number of occurrences > of a value that're required to make ANALYZE decide it is a "most common > value"... > > Second, the code also has a rule that potential MCVs need to have an > estimated frequency at least

[HACKERS] PG10 Partitioned tables and relation_is_updatable()

Hi, It looks like relation_is_updatable() didn't get the message about partitioned tables. Thus, for example, information_schema.views and information_schema.columns report that simple views built on top of partitioned tables are non-updatable, which is wrong. Attached is a patch to fix this. I

Re: [HACKERS] Statistics "dependency"

On 23 April 2017 at 03:37, Bruce Momjian wrote: > In looking at the new multi-column statistics "dependency" option in > Postgres 10, I am quite confused by the term "dependency". Wouldn't > "correlation" be clearer and less confusing as "column dependency" > already means

Re: [HACKERS] WITH clause in CREATE STATISTICS

On 21 April 2017 at 01:21, Tomas Vondra wrote: > On 04/21/2017 12:13 AM, Tom Lane wrote: >> >> Alvaro Herrera writes: >>> >>> Simon just pointed out that having the WITH clause appear in the middle >>> of the CREATE STATISTICS command looks

Re: [HACKERS] multivariate statistics (v19)

On 11 February 2017 at 01:17, Tomas Vondra wrote: > Thanks for the feedback, I'll fix this. I've allowed myself to be a bit > sloppy because the number of attributes in the statistics is currently > limited to 8, so the overflows are currently not an issue. But it

Re: [HACKERS] multivariate statistics (v19)

On 8 February 2017 at 16:09, David Fetter wrote: > Combinations are n!/(k! * (n-k)!), so computing those is more > along the lines of: > > unsigned long long > choose(unsigned long long n, unsigned long long k) { > if (k > n) { > return 0; > } > unsigned long

Re: [HACKERS] multivariate statistics (v19)

On 6 February 2017 at 21:26, Alvaro Herrera wrote: > Tomas Vondra wrote: >> On 02/01/2017 11:52 PM, Alvaro Herrera wrote: > >> > Nearby, some auxiliary functions such as n_choose_k and >> > num_combinations are not documented. What it is that they do? I'd >> > move these

Re: [HACKERS] Improving RLS planning

On 29 December 2016 at 15:55, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dean Rasheed <dean.a.rash...@gmail.com> writes: >> On 28 December 2016 at 19:12, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> [ getting back to this patch finally... ] I made the suggested chan

Re: [HACKERS] Improving RLS planning

On 28 December 2016 at 19:12, Tom Lane <t...@sss.pgh.pa.us> wrote: > Stephen Frost <sfr...@snowman.net> writes: >> * Dean Rasheed (dean.a.rash...@gmail.com) wrote: >>> Hmm. I've not read any of the new code yet, but the fact that this >>> test now reduces to

Re: [HACKERS] CREATE OR REPLACE VIEW bug

On 17 December 2016 at 15:42, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > It seems that there is a bug in CREATE OR REPLACE VIEW... > > DefineView()/DefineVirtualRelation() will need a little re-jigging to > do things in the required order. ...and the required order for ex

[HACKERS] CREATE OR REPLACE VIEW bug

It seems that there is a bug in CREATE OR REPLACE VIEW's handling of WITH CHECK OPTION (noticed while thinking about the recent change to pg_dump's handling of circular dependencies in views -- d8c05af). If you use CREATE OR REPLACE VIEW on a view that isn't auto-updatable and turn it into one

Re: [HACKERS] Add support for restrictive RLS policies

Stephen, I looked through this in a little more detail and I found one other issue: the documentation for the system catalog table pg_policy and the view pg_policies needs to be updated to include the new columns that have been added. Other than that, it all looks good to me, subject to the

Re: [HACKERS] Add support for restrictive RLS policies

On 1 December 2016 at 14:38, Stephen Frost <sfr...@snowman.net> wrote: > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: >> In get_policies_for_relation() ... >> ... I think it should sort the restrictive policies by name > > Hmmm, is it really the case that the qua

Re: [HACKERS] Add support for restrictive RLS policies

On 30 November 2016 at 21:54, Stephen Frost wrote: > Unless there's further comments, I'll plan to push this sometime > tomorrow. > Sorry I didn't have time to look at this properly. I was intending to, but my day job just keeps getting in the way. I do have a couple of

Re: [HACKERS] Improving RLS planning

On 28 November 2016 at 23:55, Stephen Frost wrote: >> diff --git a/src/test/regress/expected/updatable_views.out >> b/src/test/regress/expected/updatable_views.out > [...] >> --- 2104,2114 >> >> EXPLAIN (VERBOSE, COSTS OFF) >> UPDATE v1 SET a=100 WHERE snoop(a) AND

Re: [HACKERS] Improving RLS planning

On 10 November 2016 at 17:12, Tom Lane wrote: > Yeah, I think we'd be best off to avoid the bare term "security". > It's probably too late to change the RTE field name "securityQuals", > but maybe we could uniformly call those "security barrier quals" in > the comments. Then

Re: [HACKERS] Improving RLS planning

On 8 November 2016 at 16:46, Robert Haas wrote: > On Thu, Nov 3, 2016 at 6:23 PM, Tom Lane wrote: >>> I think that ordering might be sub-optimal if you had a mix of >>> leakproof quals and security quals and the cost of some security quals >>> were

Re: [HACKERS] Improving RLS planning

On 8 November 2016 at 14:45, Tom Lane wrote: > Stephen Frost writes: >> * Tom Lane (t...@sss.pgh.pa.us) wrote: >>> * Since the planner is now depending on Query.hasRowSecurity to be set >>> whenever there are any securityQuals, I put in an Assert about

Re: [HACKERS] Improving RLS planning

On 25 October 2016 at 22:58, Tom Lane wrote: > The alternative I'm now thinking about pursuing is to get rid of the > conversion of RLS quals to subqueries. Instead, we can label individual > qual clauses with security precedence markings. Concretely, suppose we > add an

Re: [HACKERS] multivariate statistics (v19)

On 4 October 2016 at 09:15, Heikki Linnakangas wrote: > However, for tables and views, each object you store in those views is a > "table" or "view", but with this thing, the object you store is > "statistics". Would you have a catalog table called "pg_scissor"? > No, probably

Re: [HACKERS] multivariate statistics (v19)

On 30 September 2016 at 12:10, Heikki Linnakangas wrote: > I fear that using "statistics" as the name of the new object might get a bit > awkward. "statistics" is a plural, but we use it as the name of a single > object, like "pants" or "scissors". Not sure I have any better

Re: [HACKERS] multivariate statistics (v19)

On 4 October 2016 at 04:25, Michael Paquier wrote: > OK. A second thing was related to the use of schemas in the new system > catalogs. As mentioned in [1], those could be removed. > [1]: >

Re: [HACKERS] multivariate statistics (v19)

On 3 August 2016 at 02:58, Tomas Vondra wrote: > Attached is v19 of the "multivariate stats" patch series Hi, I started looking at this - just at a very high level - I've not read much of the detail yet, but here are some initial review comments. I think the

Re: [HACKERS] CREATE POLICY bug ?

[Please reply to the list, not just to me, so that others can benefit from and contribute to the discussion] On 31 August 2016 at 11:52, Andrea Adami wrote: > Thnaks Dean, i did further investigations: > i set the owner of the view to: "mana...@scuola247.it" with: > ALTER TABLE

Re: [HACKERS] RLS related docs

On 28 August 2016 at 21:23, Joe Conway wrote: > Apologies for the delay, but new patch attached. Assuming no more > comments, will commit this, backpatched to 9.5, in a day or two. > Looking at this again, I think there is something fishy about these dump/restore flags. If

Re: [HACKERS] CREATE POLICY bug ?

On 20 August 2016 at 03:15, Andrea Adami wrote: > when i run the query: "select * from public.policy_view" > the ouput is the same (all rows) for all users > i'm doing some mistakes or this is a bug ? > No, it looks correct to me. When going through a view, the policies and

Re: [HACKERS] Bogus ANALYZE results for an otherwise-unique column with many nulls

On 5 August 2016 at 21:48, Tom Lane wrote: > OK, thanks. What shall we do about Andreas' request to back-patch this? > I'm personally willing to do it, but there is the old bugaboo of "maybe > it will destabilize a plan that someone is happy with". > My inclination would be

Re: [HACKERS] Combining hash values

On 1 August 2016 at 08:19, Greg Stark wrote: > Surely combining multiple hashes is the same problem as hashing a block of > memory? Shouldn't we just use the same algorithm as hash_any()? > Yes, I imagine that should work well. I suspect that Thomas's proposal would also probably

Re: [HACKERS] Optimizing numeric SUM() aggregate

On 27 July 2016 at 10:17, Andrew Borodin wrote: >> if (accum->maxdig > (INT_MAX - INT_MAX / NBASE) / (NBASE - 1)) > Woth noting that (INT_MAX - INT_MAX / NBASE) / (NBASE - 1) == INT_MAX > / NBASE for any NBASE > 1 Interesting. I think it's clearer the way it is in

Re: [HACKERS] Optimizing numeric SUM() aggregate

On 27 July 2016 at 09:57, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > it could be > coded using something like > > accum->maxdig += NBASE - 1; > if (accum->maxdig > (INT_MAX - INT_MAX / NBASE) / (NBASE - 1)) > Propagate carries... > Oops, t

Re: [HACKERS] Optimizing numeric SUM() aggregate

On 27 July 2016 at 07:33, Andrew Borodin wrote: >>I think we could do carry every 0x7FF / 1 accumulation, couldn't we? > > I feel that I have to elaborate a bit. Probably my calculations are wrong. > > Lets assume we already have accumulated INT_MAX of digits in

Re: [HACKERS] Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

On 30 May 2016 at 15:44, Andrew Gierth <and...@tao11.riddles.org.uk> wrote: >>>>>> "Dean" == Dean Rasheed <dean.a.rash...@gmail.com> writes: > > Dean> That may be so, but we already support FILTER for all windows > Dean> functions as well

Re: [HACKERS] Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

On 23 May 2016 at 17:01, Jeff Davis wrote: > On Fri, May 20, 2016 at 1:41 PM, David G. Johnston > wrote: >> How does the relatively new FILTER clause play into this, if at all? > > My interpretation of the standard is that FILTER is not allowable

Re: [HACKERS] RLS related docs

On 25 May 2016 at 02:04, Joe Conway wrote: > Please see attached two proposed patches for the docs related to RLS: > > 1) Correction to pg_restore > 2) Additional mentions that "COPY FROM" does not allow RLS to be enabled > > Comments? > The pg_restore change looks good --

Re: [HACKERS] psql :: support for \ev viewname and \sv viewname

On 4 May 2016 at 13:23, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 5/4/16 3:21 AM, Dean Rasheed wrote: >> Well, appendStringLiteralAH() takes both, so that sets a precedent. > Works for me. Could you supply an updated patch with a static function > instea

Re: [HACKERS] More inaccurate results from numeric pow()

On 2 May 2016 at 18:38, Tom Lane wrote: > I don't much care for the hardwired magic number here, especially since > exp_var() does not have its limit expressed as "6000" but as > "NUMERIC_MAX_RESULT_SCALE * 3". I think you should rephrase the limit > to use that expression,

Re: [HACKERS] psql :: support for \ev viewname and \sv viewname

On 4 May 2016 at 01:35, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 5/3/16 3:10 PM, Dean Rasheed wrote: >> On 3 May 2016 at 16:52, Peter Eisentraut >>> >>> I would change appendReloptionsArrayAH() to a function and keep AH as the >>>

Re: [HACKERS] psql :: support for \ev viewname and \sv viewname

On 3 May 2016 at 16:52, Peter Eisentraut wrote: > I would change appendReloptionsArrayAH() to a function and keep AH as the > first argument (similar to other functions that take such a handle). I can understand changing it to a function, but I don't think AH

Re: [HACKERS] More inaccurate results from numeric pow()

On 2 May 2016 at 19:40, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, May 2, 2016 at 1:02 PM, Dean Rasheed <dean.a.rash...@gmail.com> wrote: >> Doing some more testing of the numeric code patched in [1] I noticed >> another case where the result is inaccurate --

[HACKERS] More inaccurate results from numeric pow()

Doing some more testing of the numeric code patched in [1] I noticed another case where the result is inaccurate -- computing 0.12 ^ -2345.6 gives a very large number containing 2162 digits, but only the first 2006 correct, while the last 156 digits are wrong. The reason is this code in

Re: [HACKERS] psql :: support for \ev viewname and \sv viewname

On 27 April 2016 at 08:36, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > Here is a rough patch based on the way pg_dump handles this. It still > needs a bit of polishing -- in particular I think fmtReloptionsArray() > (copied from pg_dump) should probably be moved to st

Re: [HACKERS] psql :: support for \ev viewname and \sv viewname

[Looking back over old threads] On 22 July 2015 at 22:00, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > This appears to be missing support for view options (WITH CHECK OPTION > and security_barrier), so editing a view with either of those options > will cause them to be stripped

Re: [HACKERS] [COMMITTERS] pgsql: Add trigonometric functions that work in degrees.

On 26 April 2016 at 16:26, Tom Lane wrote: > The next time somebody proposes that we can get exact results out of > floating-point arithmetic, I'm going to run away screaming. > Yeah, I think I will have the same reaction. Thanks for all your hard work getting this to work.

Re: [HACKERS] Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.

On 26 April 2016 at 04:48, Andres Freund wrote: > No, I think we got to do this in all branches. I was just wondering > about how to fix vm_extend(). Which I do think we got to fix, even in > the back-branches. > I think replacing CacheInvalidateSmgr() with

Re: [HACKERS] [COMMITTERS] pgsql: Add trigonometric functions that work in degrees.

On 26 April 2016 at 04:25, Tom Lane wrote: > In short, these tests suggest that we need a coding pattern like > this: > > volatile float8 asin_x = asin(x); > return (asin_x / asin_0_5) * 30.0; > > We could drop the "volatile" by adopting -ffloat-store, but that

Re: [HACKERS] [COMMITTERS] pgsql: Add trigonometric functions that work in degrees.

On 19 April 2016 at 14:38, Tom Lane wrote: > Yeah, what I was thinking of printing is something like > > asind(x), > asind(x) IN (-90,-30,0,30,90) AS asind_exact, > ... > > with extra_float_digits=3. The point of this is not necessarily to give > any

Re: [HACKERS] [COMMITTERS] pgsql: Add trigonometric functions that work in degrees.

On 19 April 2016 at 05:16, Noah Misch wrote: > On Mon, Apr 18, 2016 at 11:56:55PM -0400, Tom Lane wrote: >> Noah Misch writes: >> > On Mon, Apr 18, 2016 at 10:22:59PM -0400, Tom Lane wrote: >> >> We could alternatively set extra_float_digits to its max value

Re: [HACKERS] improving GROUP BY estimation

On 31 March 2016 at 22:02, Tom Lane wrote: > I'm just concerned about what happens when the Dellera paper stops being > available. I don't mind including that URL as a backup to the written-out > argument I just suggested. > Here's an updated patch with references to both

Re: [HACKERS] improving GROUP BY estimation

On 31 March 2016 at 21:40, Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> Another minor gripe is the use of a random URL as justification. This >>> code will still be around when that URL exists nowhere but the Wayback >>> Machine.

Re: [HACKERS] improving GROUP BY estimation

On 31 March 2016 at 20:18, Tom Lane wrote: > Also, I wonder if it'd be a good idea to provide a guard against division > by zero --- we know rel->tuples > 0 at this point, but I'm less sure that > reldistinct can't be zero. In the same vein, I'm worried about the first >

Re: [HACKERS] improving GROUP BY estimation

On 30 March 2016 at 14:03, Tomas Vondra wrote: > Attached is v4 of the patch Thanks, I think this is good to go, except that I think we need to use pow() rather than powl() because AIUI powl() is new to C99, and so won't necessarily be available on all supported

Re: [HACKERS] Re: Add generate_series(date,date) and generate_series(date,date,integer)

On 16 March 2016 at 23:32, David Steele wrote: > On 3/10/16 1:24 PM, Corey Huinker wrote: > >> New patch for Alvaro's consideration. >> >> Very minor changes since the last time, the explanations below are >> literally longer than the changes: >> - Rebased,

Re: [HACKERS] improving GROUP BY estimation

On 18 March 2016 at 00:37, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: >> On Sun, 2016-03-13 at 15:24 +, Dean Rasheed wrote: >>> I think that a better formula to use would be >>> >>> reldistinct *= (1 - powl(1 - rel-rows / rel->tuples, rel->t

Re: [HACKERS] improving GROUP BY estimation

On 4 March 2016 at 13:10, Tomas Vondra wrote: > The risk associated with over-estimation is that we may switch from > HashAggregate to GroupAggregate, and generally select paths better > suited for large number of rows. Not great, because the plan may not be >

Re: [HACKERS] custom function for converting human readable sizes to bytes

On 18 February 2016 at 10:05, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > OK, I'll add a check for that. > Thanks for testing. > Pushed, with a catversion bump. Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your sub

Re: [HACKERS] custom function for converting human readable sizes to bytes

On 18 February 2016 at 02:00, Vitaly Burovoy wrote: >> + else >> + have_digits = false; > Does it worth to move it to the declaration and remove that "else" block? > + boolhave_digits = false; OK, that's probably a bit neater. > Is it

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

On 17 February 2016 at 02:32, Jim Nasby <jim.na...@bluetreble.com> wrote: > On 2/11/16 4:21 AM, Dean Rasheed wrote: >> >> Thinking about this some more though, perhaps*sorting* the columns is >> the wrong way to be thinking about it. Perhaps a better approach would

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

On 15 February 2016 at 14:08, Daniel Verite <dan...@manitou-mail.org> wrote: > Dean Rasheed wrote: > >> My biggest problem is with the sorting, for all the reasons discussed >> above. There is absolutely no reason for \crosstabview to be >> re-sorting ro

Re: [HACKERS] custom function for converting human readable sizes to bytes

On 17 February 2016 at 00:39, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: > On 2/16/16, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote: >> On 2/16/16, Dean Rasheed <dean.a.rash...@gmail.com> wrote: >>> Fixing that in parse_memory_unit() would be messy beca

Re: [HACKERS] custom function for converting human readable sizes to bytes

On 16 February 2016 at 05:01, Pavel Stehule <pavel.steh...@gmail.com> wrote: > 2016-02-15 10:16 GMT+01:00 Dean Rasheed <dean.a.rash...@gmail.com>: >> Is there any reason not to make >> pg_size_bytes() return numeric? >> > This is a question. I have not a stron

Re: [HACKERS] custom function for converting human readable sizes to bytes

> On 12/02/16 10:19, Dean Rasheed wrote: >> This seems like a reasonable first patch for me as a committer, so >> I'll take it unless anyone else was planning to do so. > So looking at this, it seems that for the most part pg_size_bytes() will parse any output produced

Re: [HACKERS] custom function for converting human readable sizes to bytes

On 12 February 2016 at 06:25, Pavel Stehule wrote: > Thank you for review and other work > This seems like a reasonable first patch for me as a committer, so I'll take it unless anyone else was planning to do so. Regards, Dean -- Sent via pgsql-hackers mailing list

Re: [HACKERS] max_parallel_degree context level

On 11 February 2016 at 13:18, Robert Haas wrote: > On Thu, Feb 11, 2016 at 7:40 AM, Thom Brown wrote: >> As it currently stands, max_parallel_degree is set to a superuser >> context > > I don't have a clue why it's like that. It seems like it should be >

  1   2   3   4   5   6   7   >