Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

> On Nov 10, 2017, at 3:58 PM, Stephen Frost wrote: > > Michael, Tom, > > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> On Fri, Nov 10, 2017 at 10:00 AM, Tom Lane wrote: >>> Stephen Frost writes: I'm guessing no,

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

> On Sep 12, 2017, at 2:06 PM, Tomas Vondra > wrote: > > Attached is an updated version of the patch, dealing with fallout of > 821fb8cdbf700a8aadbe12d5b46ca4e61be5a8a8 which touched the SGML > documentation for CREATE STATISTICS. Your patches need updating.

Re: [HACKERS] Add some const decorations to prototypes

> On Oct 31, 2017, at 7:46 AM, Peter Eisentraut > wrote: > > Here is a patch that adds const decorations to many char * arguments in > functions. It should have no impact otherwise; there are very few code > changes caused by it. Some functions have a

Re: [HACKERS] proposal: schema variables

> Comments, notes? How would variables behave on transaction rollback? CREATE TEMP VARIABLE myvar; SET myvar := 1; BEGIN; SET myvar := 2; COMMIT; BEGIN; SET myvar := 3; ROLLBACK; SELECT myvar; How would variables behave when modified in a procedure that aborts rather than returning cleanly?

Re: [HACKERS] md5 still listed as an option in pg_hba.conf.sample

> On Sep 26, 2017, at 10:36 AM, Bruce Momjian <br...@momjian.us> wrote: > > On Tue, Sep 26, 2017 at 10:23:55AM -0700, Mark Dilger wrote: >> The comment that I think needs updating is: >> >> # METHOD can be "trust", "reject", "md5",

[HACKERS] md5 still listed as an option in pg_hba.conf.sample

The comment that I think needs updating is: # METHOD can be "trust", "reject", "md5", "password", "scram-sha-256", # "gss", "sspi", "ident", "peer", "pam", "ldap", "radius" or "cert". The "md5" option no longer works, as discussed in other threads. mark -- Sent via pgsql-hackers mailing

Re: [HACKERS] Renaming PG_GETARG functions (was Re: PG_GETARG_GISTENTRY?)

> On Sep 12, 2017, at 1:07 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > [ changing subject line to possibly draw more attention ] > > Mark Dilger <hornschnor...@gmail.com> writes: >>> On Apr 5, 2017, at 9:23 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

> On Aug 10, 2017, at 11:20 AM, Robert Haas <robertmh...@gmail.com> wrote: > > On Wed, Jul 5, 2017 at 12:14 AM, Mark Dilger <hornschnor...@gmail.com> wrote: >> I can understand this, but wonder if I could use something like >> >> FOR I TOTALLY PROMISE

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 19, 2017, at 9:53 AM, Robert Haas wrote: > > On Mon, Jul 17, 2017 at 6:12 PM, Tom Lane wrote: >> So, thinking about how that would actually work ... the thing to do in >> order to preserve existing on-disk values is to alternate between

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 19, 2017, at 10:23 AM, Robert Haas wrote: > > On Wed, Jul 19, 2017 at 1:12 PM, Tom Lane wrote: >>> Doesn't this plan amount to breaking pg_upgrade compatibility and >>> hoping that nobody notice? >> >> Well, what we'd need to do is document

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 18, 2017, at 9:13 PM, Mark Dilger <hornschnor...@gmail.com> wrote: > >> >> On Jul 17, 2017, at 2:34 PM, Mark Dilger <hornschnor...@gmail.com> wrote: >> >>> >>> On Jul 17, 2017, at 2:14 PM, Tom Lane <t...@sss.pgh.pa.us>

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 17, 2017, at 2:34 PM, Mark Dilger <hornschnor...@gmail.com> wrote: > >> >> On Jul 17, 2017, at 2:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> Mark Dilger <hornschnor...@gmail.com> writes: >>>> On Jul 17, 2017, at 12:54

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 17, 2017, at 3:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >>> On Jul 17, 2017, at 2:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Well, if you or somebody is willing to do the legwo

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 17, 2017, at 3:56 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >> On Jul 17, 2017, at 3:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Now, this should mostly work conveniently, except t

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 17, 2017, at 3:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >>> On Jul 17, 2017, at 2:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Well, if you or somebody is willing to do the legwo

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 17, 2017, at 2:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >>> On Jul 17, 2017, at 12:54 PM, Mark Dilger <hornschnor...@gmail.com> wrote: >> On Jul 15, 2017, at 3:00 PM, Tom Lane <t...

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 17, 2017, at 12:54 PM, Mark Dilger <hornschnor...@gmail.com> wrote: > > >> On Jul 15, 2017, at 3:00 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> The types abstime, reltime, and tinterval need to go away, or be >> reimplemented, some

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 15, 2017, at 3:00 PM, Tom Lane wrote: > > The types abstime, reltime, and tinterval need to go away, or be > reimplemented, sometime well before 2038 when they will overflow. > It's not too soon to start having a plan for that, especially seeing > that it seems to

Re: [HACKERS] Revisiting NAMEDATALEN

> On Jul 7, 2017, at 2:53 AM, Emrul wrote: > > Tom, thank you for that pointer. I get now that it is not free and therefore > why its not something that should be changed by default. > > I guess the problem is 'build your own copy' (i.e. compiling from source) is > something

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

> On Jul 5, 2017, at 5:30 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Jul 5, 2017 at 9:44 AM, Mark Dilger <hornschnor...@gmail.com> wrote: >> >>> On Jul 3, 2017, at 10:25 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: >>>

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

> On Jul 3, 2017, at 10:25 PM, Amit Kapila wrote: > > On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs wrote: >> On 30 June 2017 at 05:14, Amit Kapila wrote: >> >>> This is explained in section 15.2 [1], refer below para:

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

> On Jun 29, 2017, at 8:55 PM, Mark Dilger <hornschnor...@gmail.com> wrote: > > > Changing myfunc to create a temporary table, to execute the sql to populate > that temporary table, and to then loop through the temporary table's rows > fixes the problem. For the real-w

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

> On Jun 29, 2017, at 9:14 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Fri, Jun 30, 2017 at 9:25 AM, Mark Dilger <hornschnor...@gmail.com> wrote: >> Hackers, >> >> In src/pl/plpgsql/src/pl_exec.c: exec_run_select intentionally does n

[HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

Hackers, In src/pl/plpgsql/src/pl_exec.c: exec_run_select intentionally does not allow a parallel plan if a portal will be returned. This has the practical consequence that a common coding practice (at least for me) of doing something like: create function myfunc(arg1 text, arg2 text) returns

Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity

> On Jun 4, 2017, at 2:19 PM, Andres Freund <and...@anarazel.de> wrote: > > On 2017-06-04 14:16:14 -0700, Mark Dilger wrote: >> Sorry, I was not clear. What I meant to get at was that if you remove from >> the >> executor all support for SRFs inside cas

Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity

> On Jun 4, 2017, at 12:35 PM, Andres Freund <and...@anarazel.de> wrote: > > Hi Mark, > > On 2017-06-04 11:55:03 -0700, Mark Dilger wrote: >>> Yea, I'm not a big fan of the either the pre v10 or the v10 behaviour of >>> SRFs inside coalesce/case.

Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity

> On Jun 4, 2017, at 11:55 AM, Mark Dilger <hornschnor...@gmail.com> wrote: > > SELECT x, CASE WHEN y THEN SUM(generate_series(1,z)) ELSE 5 END > FROM table_with_columns_x_and_y; Sorry, this table is supposed to be the same as the previous one, table_with_col

Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity

y is false. That could be changed with an aggregate function such as: SELECT x, CASE WHEN y THEN SUM(generate_series(1,z)) ELSE 5 END FROM table_with_columns_x_and_y; Which to me gives one output row per table row regardless of whether y is true. Thanks, and my apologies if I am m

Re: [HACKERS] pg_class.relpartbound definition overly brittle

gt; own rationale. Maybe you'd like to complain that every one of those > rationales is wrongheaded but I do not think you will get far. > > I think the best advice for Mark is to look at pg_get_expr() output and > see if that matches. Yes, I'm already doing that based on the discussion so f

Re: [HACKERS] pg_class.relpartbound definition overly brittle

> On Jun 1, 2017, at 6:31 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >> When you guys commit changes that impact partitioning, I notice, and change >> my code to match. But in this case, it seemed to me

Re: [HACKERS] pg_class.relpartbound definition overly brittle

> On May 31, 2017, at 6:32 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> > wrote: > > On 2017/06/01 4:50, Robert Haas wrote: >> On Wed, May 31, 2017 at 3:40 PM, Mark Dilger <hornschnor...@gmail.com> wrote: >>> recent changes have introduced t

Re: [HACKERS] pg_class.relpartbound definition overly brittle

> On May 31, 2017, at 4:00 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > Mark Dilger wrote: > >>>> >>>>

Re: [HACKERS] pg_class.relpartbound definition overly brittle

> On May 31, 2017, at 3:42 PM, Andres Freund <and...@anarazel.de> wrote: > > On 2017-05-31 15:38:58 -0700, Mark Dilger wrote: >>> Normal users aren't going to make sense of node trees in the first >>> place. You should use pg_get_expr for it: >>&

Re: [HACKERS] pg_class.relpartbound definition overly brittle

> On May 31, 2017, at 3:17 PM, Andres Freund <and...@anarazel.de> wrote: > > On 2017-05-31 15:06:06 -0700, Mark Dilger wrote: >> That's cold comfort, given that most users will be looking at the pg_class >> table and not writing C code that compares Node objects. I w

Re: [HACKERS] pg_class.relpartbound definition overly brittle

> On May 31, 2017, at 2:49 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > Mark Dilger wrote: >> Hackers, >> >> recent changes have introduced the :location field to the partboundspec >> in pg_catalog.pg_class. This means that if two identica

[HACKERS] pg_class.relpartbound definition overly brittle

fields for those two tables could show up as different. Can we perhaps remove the :location field here? If not, could somebody please defend why this belongs in the catalog entries for the table? Sorry if I am missing something obvious... Thanks, Mark Dilger -- Sent via pgsql-hackers mailing

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

> On May 31, 2017, at 7:58 AM, Bruce Momjian <br...@momjian.us> wrote: > > On Wed, May 31, 2017 at 07:53:22AM -0700, Mark Dilger wrote: >>> Just to clarify, the TEMPORARY clause would allow the tablespace to >>> start up empty, while normal tablespaces can't do

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

> On May 31, 2017, at 6:04 AM, Bruce Momjian <br...@momjian.us> wrote: > > On Wed, May 31, 2017 at 07:53:53AM -0400, Robert Haas wrote: >> On Tue, May 30, 2017 at 6:50 PM, Mark Dilger <hornschnor...@gmail.com> wrote: >>>> On May 29, 2017, at 11:53 AM,

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

ject wanted to extend the grammar and behavior in this direction, maybe temp_tablespaces would work that way? I'm not so familiar with what the temp_tablespaces GUC is for -- only ever implemented what I described above. Mark Dilger -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql

[HACKERS] syscache entries out of order

pedantry. Patch attached. Mark Dilger syscache.patch.0 Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Event triggers + table partitioning cause server crash in current master

> On May 15, 2017, at 9:37 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> > wrote: > > On 2017/05/16 1:18, Mark Dilger wrote: >> >>> On May 15, 2017, at 6:49 AM, Mark Dilger <hornschnor...@gmail.com> wrote: >>> >>> I can confirm

Re: [HACKERS] Hash Functions

must be allowed in the hash partitioning implementation; just that it does make sense if you squint and look a bit sideways at it. Mark Dilger -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Event triggers + table partitioning cause server crash in current master

> On May 15, 2017, at 6:49 AM, Mark Dilger <hornschnor...@gmail.com> wrote: > > I can confirm that this fixes the crash that I was seeing. I have read > through the patch briefly, but will give it a more thorough review in the > next few hours. My only negative comme

Re: [HACKERS] Event triggers + table partitioning cause server crash in current master

> On May 14, 2017, at 11:02 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> > wrote: > > On 2017/05/14 12:03, Mark Dilger wrote: >> Hackers, >> >> I discovered a reproducible crash using event triggers in the current >> development version, 29c7

[HACKERS] Event triggers + table partitioning cause server crash in current master

et me know if you need them. I built using the command ./configure --enable-cassert --enable-tap-tests && make -j4 && make check Mark Dilger to_reproduce_bug.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] idea: custom log_line_prefix components besides application_name

> On May 9, 2017, at 3:14 PM, Chapman Flack <c...@anastigmatix.net> wrote: > > On 05/09/2017 01:25 PM, Mark Dilger wrote: > >> Consensus, no, but utility, yes. >> >> In three tier architectures there is a general problem that the database >&g

Re: [HACKERS] idea: custom log_line_prefix components besides application_name

the logs, but stored procedures that work in support of the middle tier might want it for locale information, etc. As things currently stand, there is no good way to get this passed all the way down into the database stored procedure that needs it, given that you are typically calling down through th

Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER name HANDLER ...

> On May 9, 2017, at 12:18 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> > wrote: > > Hi, > > On 2017/05/05 9:38, Mark Dilger wrote: >> Hackers, >> >> just FYI, I cannot find any regression test coverage of this part of the >> grammar, no

[HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER name HANDLER ...

for the noise if this is already common knowledge. Also, if I'm wrong, I'd appreciate a pointer to the test that I am failing to find. Thanks, Mark Dilger -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders

. Is there a bug there? > > I remain of the opinion that if we can't tell from the transmitted > data whether a timeline switch has caused the position to go backward, > then that's a protocol shortcoming that ought to be fixed. The recent fix in 546c13e11b29a5408b9d6a6e3cca301380b47f

Re: [HACKERS] PG_GETARG_GISTENTRY?

> On Apr 5, 2017, at 1:27 PM, Mark Dilger <hornschnor...@gmail.com> wrote: > > >> On Apr 5, 2017, at 1:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> Mark Dilger <hornschnor...@gmail.com> writes: >>> I have written a patch to fi

Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders

> On Apr 22, 2017, at 11:40 AM, Tom Lane wrote: > > I wrote: >> Whoa. This just turned into a much larger can of worms than I expected. >> How can it be that processes are getting assertion crashes and yet the >> test framework reports success anyway? That's impossibly >>

Re: [HACKERS] [sqlsmith] Planner crash on foreign table join

> On Apr 8, 2017, at 7:41 PM, Mark Dilger <hornschnor...@gmail.com> wrote: > > >> On Apr 8, 2017, at 7:35 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> Mark Dilger <hornschnor...@gmail.com> writes: >>> This is very near where the or

Re: [HACKERS] [sqlsmith] Planner crash on foreign table join

> On Apr 8, 2017, at 7:35 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >> This is very near where the original crash reported in this thread was >> crashing, probably only >> different due to the extra lines o

Re: [HACKERS] [sqlsmith] Planner crash on foreign table join

> On Apr 8, 2017, at 6:48 PM, Mark Dilger <hornschnor...@gmail.com> wrote: > > >> On Apr 8, 2017, at 6:38 PM, Mark Dilger <hornschnor...@gmail.com> wrote: >> >> >>> On Apr 8, 2017, at 5:13 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >

Re: [HACKERS] [sqlsmith] Planner crash on foreign table join

> On Apr 8, 2017, at 6:38 PM, Mark Dilger <hornschnor...@gmail.com> wrote: > > >> On Apr 8, 2017, at 5:13 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> I wrote: >>> Robert Haas <robertmh...@gmail.com> writes: >>>> On Sat, A

Re: [HACKERS] [sqlsmith] Planner crash on foreign table join

> On Apr 8, 2017, at 5:13 PM, Tom Lane wrote: > > I wrote: >> Robert Haas writes: >>> On Sat, Apr 8, 2017 at 3:57 PM, Tom Lane wrote: >>> I think it's pretty dubious to change this, honestly. Just because it >>> would have caught

Re: [HACKERS] Uninitialized variable introduced in 3217327053638085d24dd4d276e7c1f7ac2c4c6b

> On Apr 6, 2017, at 8:33 AM, Peter Eisentraut > <peter.eisentr...@2ndquadrant.com> wrote: > > On 4/6/17 10:59, Mark Dilger wrote: >> Can you perhaps initialize the variable 'address' to suppress the warning? >> Thanks. > > A potential fix for this has be

[HACKERS] Uninitialized variable introduced in 3217327053638085d24dd4d276e7c1f7ac2c4c6b

Peter, Can you perhaps initialize the variable 'address' to suppress the warning? Thanks. Mark Dilger tablecmds.c:5984:6: warning: variable 'address' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] if (generatedEl

Re: [HACKERS] PG_GETARG_GISTENTRY?

> On Apr 5, 2017, at 1:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >> I have written a patch to fix these macro definitions across src/ and >> contrib/. >> Find the patch, attached. All regression t

Re: [HACKERS] PG_GETARG_GISTENTRY?

n to use PG_GETARG_*_P where PG_GETARG_*_PP might be more efficient. Varbit's bitoctetlength function could detoast only the header ala PG_DETOAST_DATUM_SLICE to return the octet length, rather than detoasting the whole thing. But that seems a different issue, and patches to change that might hav

Re: [HACKERS] Monitoring roles patch

> On Mar 28, 2017, at 1:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >> I don't see anything wrong with adding roles in pg_authid.h with a #define'd >> Oid. That's actually pretty helpful for anyone writ

Re: [HACKERS] Monitoring roles patch

> On Mar 28, 2017, at 11:52 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >> After a bit of introspection, I think what is really bothering me is not the >> inability to revoke permissions, since as you say I can

Re: [HACKERS] Monitoring roles patch

> On Mar 28, 2017, at 11:06 AM, Mark Dilger <hornschnor...@gmail.com> wrote: > > >> On Mar 28, 2017, at 9:47 AM, Dave Page <dp...@pgadmin.org> wrote: >> >>> Does >>> pg_read_all_stats still have access to stats for mysecuretable? >&g

Re: [HACKERS] Monitoring roles patch

> On Mar 28, 2017, at 9:47 AM, Dave Page wrote: > >> Does >> pg_read_all_stats still have access to stats for mysecuretable? > > Yes, because the ACL on the table controls reading/writing the data in > the table. It doesn't have any bearing on any kind of table metadata. > A

Re: [HACKERS] Monitoring roles patch

> On Mar 28, 2017, at 9:55 AM, Robert Haas wrote: > > On Tue, Mar 28, 2017 at 12:47 PM, Dave Page wrote: >>> I don't see any precedent in the code for having a hardcoded role, other >>> than >>> superuser, and allowing privileges based on a hardcoded

Re: [HACKERS] Monitoring roles patch

> On Mar 28, 2017, at 8:34 AM, Dave Page wrote: > > On Tue, Mar 28, 2017 at 11:31 AM, Peter Eisentraut > wrote: >> This patch touches the pg_buffercache and pg_freespacemap extensions, >> but there appear to be some files missing. > > Are

Re: [HACKERS] Hash support for grouping sets

> On Mar 23, 2017, at 11:22 AM, Andrew Gierth <and...@tao11.riddles.org.uk> > wrote: > >>>>>> "Mark" == Mark Dilger <hornschnor...@gmail.com> writes: > > Mark> You define DiscreteKnapsack to take integer weights and double > Mark

Re: [HACKERS] Hash support for grouping sets

> On Mar 22, 2017, at 8:09 AM, Mark Dilger <hornschnor...@gmail.com> wrote: > > >> On Mar 22, 2017, at 7:55 AM, Andrew Gierth <and...@tao11.riddles.org.uk> >> wrote: >> >> [snip] >> >> This thread seems to have gone quiet - is it ti

Re: [HACKERS] cast result of copyNode()

> On Mar 21, 2017, at 2:13 PM, David Steele <da...@pgmasters.net> wrote: > > Hi Mark, > > On 3/9/17 3:34 PM, Peter Eisentraut wrote: >> On 3/7/17 18:27, Mark Dilger wrote: >>> You appear to be using a #define macro to wrap a function of the same name

Re: [HACKERS] use SQL standard error code for nextval

of this in the >> archives, so it seems this was just not considered or not yet in >> existence when the error codes were introduced. Here is a patch to >> correct it. > > committed Perhaps you should add something to the release notes. Somebody could be testing fo

Re: [HACKERS] Hash support for grouping sets

> On Mar 8, 2017, at 9:40 AM, Andrew Gierth <and...@tao11.riddles.org.uk> wrote: > >>>>>> "Mark" == Mark Dilger <hornschnor...@gmail.com> writes: > > Mark> Hi Andrew, > > Mark> Reviewing the patch a bit more, I find it h

Re: [HACKERS] Hash support for grouping sets

t 8:00 AM, Mark Dilger <hornschnor...@gmail.com> wrote: > > >> On Mar 8, 2017, at 5:47 AM, Andrew Gierth <and...@tao11.riddles.org.uk> >> wrote: >> >>>>>>> "Mark" == Mark Dilger <hornschnor...@gmail.com> writes: >>

Re: [HACKERS] Hash support for grouping sets

> On Mar 8, 2017, at 5:47 AM, Andrew Gierth <and...@tao11.riddles.org.uk> wrote: > >>>>>> "Mark" == Mark Dilger <hornschnor...@gmail.com> writes: > > Mark> On my MacBook, `make check-world` gives differences in the > Mark> con

Re: [HACKERS] Hash support for grouping sets

> On Mar 8, 2017, at 2:30 AM, Andrew Gierth <and...@tao11.riddles.org.uk> wrote: > >>>>>> "Mark" == Mark Dilger <hornschnor...@gmail.com> writes: > > Mark> On linux/gcc the patch generates a warning in nodeAgg.c that is > Mark>

Re: [HACKERS] cast result of copyNode()

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: not tested Spec compliant: not tested Documentation:not tested Hi Peter, I like the patch so far, and it passes all the regression

Re: [HACKERS] Hash support for grouping sets

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: not tested Spec compliant: not tested Documentation:not tested On linux/gcc the patch generates a warning in nodeAgg.c that is fairly

Re: [HACKERS] Hash support for grouping sets

> On Mar 7, 2017, at 1:43 PM, Mark Dilger <hornschnor...@gmail.com> wrote: > > On my MacBook, `make check-world` gives differences in the contrib modules: I get the same (or similar -- didn't check) regression failure on CentOS, so this doesn't appear to be MacBook / hardware

Re: [HACKERS] Hash support for grouping sets

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: not tested Spec compliant: not tested Documentation:not tested On my MacBook, `make check-world` gives differences in the contrib

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

> On Feb 17, 2017, at 3:37 PM, Peter Eisentraut > <peter.eisentr...@2ndquadrant.com> wrote: > > On 2/17/17 16:13, Mark Dilger wrote: >> + PGAC_PROG_CC_CFLAGS_OPT([-Wc++-compat]) > > If your compiler isn't warning about anything with that, then there is >

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

a warnings, plus -Werror, in a section that is only active for platforms/compilers where we know there aren't spurious warnings? That would make detecting unintentionally introduced warnings simpler, without the use of COPT. Perhaps where the compiler is GCC or CLANG, and the platform is x86_64 red

Re: [HACKERS] pg_recvlogical.c doesn't build with --disable-integer-datetimes

t PGXS CC = @CC@ GCC = @GCC@ SUN_STUDIO_CC = @SUN_STUDIO_CC@ -CFLAGS = @CFLAGS@ +CFLAGS = @CFLAGS@ -Werror CFLAGS_VECTOR = @CFLAGS_VECTOR@ CFLAGS_SSE42 = @CFLAGS_SSE42@ That adds -Werror to the compilation of sources but not to the compilation of configure test programs. I'd be happy to h

Re: [HACKERS] Macro customizable hashtable / bitmapscan & aggregation perf

chance you could add some documentation about how this function is intended to be used and defined? See InitTupleHashIterator in src/include/nodes/execnodes.h Thanks, Mark Dilger > On Oct 9, 2016, at 4:38 PM, Andres Freund <and...@anarazel.de> wrote: > > Hi, > > Attached

Re: [HACKERS] should xlog_outdesc modify its argument?

> On Sep 27, 2016, at 11:25 PM, Heikki Linnakangas <hlinn...@iki.fi> wrote: > > On 09/28/2016 02:35 AM, Mark Dilger wrote: >> The function >> >> static void xlog_outdesc(StringInfo buf, XLogReaderState *record); >> >> in src/backend/access

[HACKERS] sloppy handling of pointers

. tsrank.c contains some arguably correct casts which I found slightly less correct than an alternative that I've attached. I'm pretty indifferent on this one, and just as happy if it is not included. Mark Dilger tidy.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] typedef FileName not const?

> I think the better fix here is to simply remove the typedef. It doesn't > seem to have much of a benefit, and makes using correct types harder as > demonstrated here. We don't even use it internally in fd.c.. > Fine by me. -- Sent via pgsql-hackers mailing list

Re: [HACKERS] gratuitous casting away const

Friends, here is another patch, this time fixing the casting away of const in the regex code. Mark Dilger regex.patch.1 Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

[HACKERS] typedef FileName not const?

doesn't seem to conflict with any code in the source tree. Since this may be seen as an external API change, I kept these changes in their own patch submission, so that it can be rejected separately if need be. Mark Dilger filename.patch.1 Description: Binary data -- Sent via pgsql-hackers mailing

[HACKERS] casting away const in comparators

have converted the casts to not cast away const. Please find my changes, attached. Mark Dilger comparators.patch.1 Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

[HACKERS] should xlog_outdesc modify its argument?

orks. Is this a bug? Do I just have to live with the unfortunate lack of orthogonality in the callback mechanisms? At the very least, there should perhaps be some documentation about how all this is intended to work. Thanks, please find my work-in-progress attempt and constify-ing these funct

Re: [HACKERS] gratuitous casting away const

> On Sep 22, 2016, at 9:14 AM, Tom Lane wrote: > > I'd call this kind of a wash, I guess. I'd be more excited about it if > the change allowed removal of an actual cast-away-of-constness somewhere. > > I suppose it's a bit of a chicken and egg situation, in that the lack >

Re: [HACKERS] gratuitous casting away const

> On Sep 20, 2016, at 1:06 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >> Would patches to not cast away const be considered? > > In general, yes, but I'm not especially in favor of something like this: > >

[HACKERS] needlessly casting away const in localtime.c

Friends, per the recent thread "gratuitous casting away const", the assignment on line 1247 of localtime.c has const lvalue and rvalue, yet casts through (char *) rather than (const char *). Fix attached. Mark Dilger localtime.c.patch Description: Binary data -- Sent via pgs

[HACKERS] gratuitous casting away const

ject's coding standards? Would patches to not cast away const be considered? Thanks, Mark Dilger -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] inappropriate use of NameGetDatum macro

/commands/proclang.c, line 466. src/backend/commands/dbcommands.c, lines 1263, 1489, 1606, 1746. Am I overlooking some reason why the code is correct as is? If not, I am attaching a patch that applies cleanly for me against master, compiles, and passes the regression tests. Thanks, Mark Dilger

Re: [HACKERS] 10.0

> On Jun 20, 2016, at 1:00 PM, David G. Johnston <david.g.johns...@gmail.com> > wrote: > > On Mon, Jun 20, 2016 at 3:08 PM, Mark Dilger <hornschnor...@gmail.com> wrote: > > > Do you have a problem with the human form and machine forms of the version > >

Re: [HACKERS] 10.0

> On Jun 20, 2016, at 11:30 AM, David G. Johnston <david.g.johns...@gmail.com> > wrote: > > On Mon, Jun 20, 2016 at 2:14 PM, Mark Dilger <hornschnor...@gmail.com> wrote: > > > On Jun 20, 2016, at 11:06 AM, Joshua D. Drake <j...@commandprompt.com> &g

Re: [HACKERS] 10.0

> On Jun 20, 2016, at 11:06 AM, Joshua D. Drake <j...@commandprompt.com> wrote: > > On 06/20/2016 10:45 AM, Mark Dilger wrote: > >>> Now maybe you have some other idea in mind, but I don't quite >>> understand what it is. >> >> I do, indeed,

Re: [HACKERS] 10.0

> On Jun 20, 2016, at 9:38 AM, David G. Johnston <david.g.johns...@gmail.com> > wrote: > > On Mon, Jun 20, 2016 at 12:28 PM, Mark Dilger <hornschnor...@gmail.com> wrote: > > > On Jun 20, 2016, at 8:53 AM, Mark Dilger <hornschnor...@gmail.com> wrote: >

Re: [HACKERS] 10.0

> On Jun 20, 2016, at 9:43 AM, Robert Haas <robertmh...@gmail.com> wrote: > > On Mon, Jun 20, 2016 at 12:26 PM, Mark Dilger <hornschnor...@gmail.com> wrote: >>> In practical effect that is exactly what your proposal does. You just feel >>> better because

  1   2   3   >