Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-01-27 Thread Fabien COELHO
Hello Corey, And here it is About the patch v3: ## DOCUMENTATION I'm wondering what pg would do on "EXISTS(SELECT 1 FROM customer)" if there are many employees. EXPLAIN suggests a seq_scan, which seems bad. With "(SELECT COUNT(*) FROM pgbench_accounts) <> 0" pg seems to generate an

[HACKERS] proposal: EXPLAIN ANALYZE formatting

2017-01-27 Thread Pavel Stehule
Hi Now EXPLAIN ANALYZE produce too wide rows for usage in presentations What do you think about possibility to implement >>optional<< alternative formatting. Now: node name (estimation) (actual) Alternative: node name (estimation) (actual) Regards Pavel Now ===

Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries

2017-01-27 Thread Craig Ringer
On 28 Jan. 2017 02:08, "Tom Lane" wrote: Kyotaro HORIGUCHI writes: > By the way the existing comment for the hook, >> * >> * We provide a function hook variable that lets loadable plugins get >> * control when ProcessUtility is called. Such

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

2017-01-27 Thread David Steele
On 1/27/17 6:47 PM, Michael Paquier wrote: On Sat, Jan 28, 2017 at 8:03 AM, Peter Eisentraut wrote: On 1/26/17 2:05 PM, Robert Haas wrote: I do not think it can be right to rename the directory and not anything else. I think this is the root of the

Re: [HACKERS] WIP: About CMake v2

2017-01-27 Thread Peter Eisentraut
On 1/27/17 6:11 PM, Andres Freund wrote: > On 2017-01-27 09:09:36 -0500, Peter Eisentraut wrote: >> My preferred scenario would be to replace the Windows build system by >> this first, then refine it, then get rid of Autoconf. >> >> The ideal timeline would be to have a ready patch to commit early

Re: [HACKERS] Removing link-time cross-module refs in contrib

2017-01-27 Thread Noah Misch
On Mon, Oct 03, 2016 at 12:29:18PM -0400, Tom Lane wrote: > Pursuant to Andres' suggestion in > https://www.postgresql.org/message-id/20161002223927.57xns3arkdg4h...@alap3.anarazel.de > attached is a draft patch that gets rid of link-time references > from hstore_plpython to both hstore and

Re: [HACKERS] COPY as a set returning function

2017-01-27 Thread Peter Eisentraut
On 1/27/17 8:07 PM, David Fetter wrote: > There are still neither regression tests nor SGML documentation. > > Are we at a point where we should add these things? One could argue about the documentation at this point, since the function is somewhat self-documenting for the time being. But

Re: [HACKERS] COPY as a set returning function

2017-01-27 Thread Peter Eisentraut
On 1/25/17 8:51 PM, Corey Huinker wrote: > # select * from copy_srf('echo "x\ty"',true) as t(x text, y text); I find these parameters weird. Just looking at this, one has no idea what the "true" means. Why not have a "filename" and a "program" parameter and make them mutually exclusive? --

Re: [HACKERS] GSoC 2017

2017-01-27 Thread Greg Stark
On 27 January 2017 at 14:52, Thomas Kellerer wrote: > > I don't have the exact syntax at hand, but it's something like this: > > create distinct type customer_id_type as integer; > create distinct type order_id_type as integer; > > create table customers (id customer_id_type

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

2017-01-27 Thread Peter Geoghegan
Hi Thomas, On Fri, Jan 27, 2017 at 5:03 PM, Thomas Munro wrote: > I have broken this up into a patch series, harmonised the private vs > shared hash table code paths better and fixed many things including > the problems with rescans and regression tests mentioned

Re: [HACKERS] COPY as a set returning function

2017-01-27 Thread David Fetter
On Wed, Jan 25, 2017 at 08:51:38PM -0500, Corey Huinker wrote: > I've put in some more work on this patch, mostly just taking Alvaro's > suggestions, which resulted in big code savings. The patch applies atop master. The test (ls) which previously crashed the backend now doesn't, and works in a

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

2017-01-27 Thread Thomas Munro
On Fri, Jan 13, 2017 at 2:36 PM, Peter Geoghegan wrote: > [...] > Yeah. That's basically what the BufFile unification process can > provide you with (or will, once I get around to implementing the > refcount thing, which shouldn't be too hard). As already noted, I'll > also want

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

2017-01-27 Thread Michael Paquier
On Sat, Jan 28, 2017 at 8:03 AM, Peter Eisentraut wrote: > On 1/26/17 2:05 PM, Robert Haas wrote: >> I do not think it can be right to rename the directory and not >> anything else. > > I think this is the root of the confusion. > > A lot of people apparently

Re: [HACKERS] pg_hba_file_settings view patch

2017-01-27 Thread Tom Lane
Haribabu Kommi writes: > [ pg_hba_rules_13.patch ] I spent awhile hacking on this, and made a lot of things better, but I'm still very unhappy about the state of the comments. You changed the APIs of a bunch of functions, often into fairly subtle things, and you did

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

2017-01-27 Thread Andres Freund
On 2017-01-27 18:06:11 -0500, Peter Eisentraut wrote: > On 1/24/17 4:47 PM, Robert Haas wrote: > > I'm not excited about starting to change pg_clog before we finish with > > xlog -> wal. Then we just have two half-done things, IMO. But I'm > > also not the only one with a commit bit. > > I

Re: [HACKERS] WIP: About CMake v2

2017-01-27 Thread Andres Freund
On 2017-01-27 09:09:36 -0500, Peter Eisentraut wrote: > My preferred scenario would be to replace the Windows build system by > this first, then refine it, then get rid of Autoconf. > > The ideal timeline would be to have a ready patch to commit early in a > development cycle, then get rid of the

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

2017-01-27 Thread Michael Paquier
On Sat, Jan 28, 2017 at 8:06 AM, Peter Eisentraut wrote: > On 1/24/17 4:47 PM, Robert Haas wrote: >> I'm not excited about starting to change pg_clog before we finish with >> xlog -> wal. Then we just have two half-done things, IMO. But I'm >> also not the only

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

2017-01-27 Thread Peter Eisentraut
On 1/24/17 4:47 PM, Robert Haas wrote: > I'm not excited about starting to change pg_clog before we finish with > xlog -> wal. Then we just have two half-done things, IMO. But I'm > also not the only one with a commit bit. I think that depends on which way you slice the overall mission. You

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

2017-01-27 Thread Peter Eisentraut
On 1/26/17 1:10 PM, Tom Lane wrote: > pg_reset_wal It's really more pg_reset_controldata, isn't it? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list

Re: [HACKERS] increasing the default WAL segment size

2017-01-27 Thread Michael Paquier
On Sat, Jan 28, 2017 at 7:29 AM, Robert Haas wrote: > On Thu, Jan 26, 2017 at 8:53 PM, Michael Paquier > wrote: >>> I've not done like the most careful review ever, but I'm in favor of the >>> general change (provided the byval thing is fixed

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

2017-01-27 Thread Peter Eisentraut
On 1/26/17 2:05 PM, Robert Haas wrote: > I do not think it can be right to rename the directory and not > anything else. I think this is the root of the confusion. A lot of people apparently consented to renaming pg_xlog with the understanding that that's it, whereas other people understood it

Re: [HACKERS] GSoC 2017

2017-01-27 Thread Peter van Hardenberg
On Fri, Jan 27, 2017 at 2:48 PM, Jim Nasby wrote: > On 1/27/17 8:17 AM, Brad DeJong wrote: > >> Add the potential for regulatory requirements to change at any time - >> sort of like timezone information. So no hard coded behavior. >> > > Well, I wish we had support for

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

2017-01-27 Thread Peter Eisentraut
On 1/26/17 1:20 PM, Fabrízio de Royes Mello wrote: > Ok, but doing in that way the syntax would be: > > COMMENT ON DATABASE CURRENT_DATABASE IS 'comment'; Yes, that's right. We also have ALTER USER CURRENT_USER already. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] WIP: About CMake v2

2017-01-27 Thread Michael Paquier
On Fri, Jan 27, 2017 at 11:09 PM, Peter Eisentraut wrote: > On 1/24/17 8:37 AM, Tom Lane wrote: >> Craig Ringer writes: >>> Personally I think we should aim to have this in as a non default build >>> mode in pg10 if it can be made

Re: [HACKERS] Allow interrupts on waiting standby

2017-01-27 Thread Michael Paquier
On Sat, Jan 28, 2017 at 2:18 AM, Robert Haas wrote: > On Fri, Jan 27, 2017 at 8:17 AM, Michael Paquier > wrote: >> There are no default clauses in the pgstat_get_wait_* routines so my >> compiler is actually complaining... > > That's exactly WHY

Re: [HACKERS] pg_hba_file_settings view patch

2017-01-27 Thread Haribabu Kommi
On Sat, Jan 28, 2017 at 5:47 AM, Tom Lane wrote: > Haribabu Kommi writes: > > On Fri, Jan 27, 2017 at 1:36 AM, Tom Lane wrote: > >> It might make sense to proceed by writing a separate patch that just > >> refactors the existing

Re: [HACKERS] GSoC 2017

2017-01-27 Thread Jim Nasby
On 1/27/17 8:17 AM, Brad DeJong wrote: Add the potential for regulatory requirements to change at any time - sort of like timezone information. So no hard coded behavior. Well, I wish we had support for storing those changing requirements as well. If we had that it would greatly simplify

Re: [HACKERS] Superowners

2017-01-27 Thread Peter Eisentraut
On 1/26/17 1:25 PM, Simon Riggs wrote: > That should include the ability to dump all objects, yet without any > security details. And it should allow someone to setup logical > replication easily, including both trigger based and new logical > replication. And GRANT ON ALL should work. This

Re: [HACKERS] pageinspect: Hash index support

2017-01-27 Thread Peter Eisentraut
On 1/18/17 10:45 AM, Jesper Pedersen wrote: > Fixed in this version: > > * verify_hash_page: Display magic in hex, like hash_metapage_info > * Update header for hash_page_type > > Moving the patch back to 'Needs Review'. Please include tests in your patch. I have posted a sample test suite in

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2017-01-27 Thread Corey Huinker
On Thu, Jan 26, 2017 at 4:06 PM, Corey Huinker wrote: > > > On Thu, Jan 26, 2017 at 3:55 PM, Fabien COELHO > wrote: > >> >> Hello Daniel, >> >> A comment about control flow and variables: in branches that are not >>> taken, variables are expanded

Re: [HACKERS] increasing the default WAL segment size

2017-01-27 Thread Robert Haas
On Thu, Jan 26, 2017 at 8:53 PM, Michael Paquier wrote: >> I've not done like the most careful review ever, but I'm in favor of the >> general change (provided the byval thing is fixed obviously). > > Thanks for the review. Why not use pg_ltoa and pg_lltoa like the

Re: [HACKERS] Proposal : For Auto-Prewarm.

2017-01-27 Thread Jim Nasby
On 1/26/17 10:11 PM, Beena Emerson wrote: In that case, we could add the file location parameter. By default it would store in the cluster directory else in the location provided. We can update this parameter in standby for it to access the file. I don't see file location being as useful in

Re: [HACKERS] Typo in comment in postgres_fdw.c

2017-01-27 Thread Robert Haas
On Thu, Jan 26, 2017 at 10:45 PM, Etsuro Fujita wrote: > I ran into a typo in a comment in contrib/postgres_fdw/postgres_fdw.c. > Attached is a small patch for fixing that. Committed, thanks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

2017-01-27 Thread David G. Johnston
On Fri, Jan 27, 2017 at 3:13 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > In any case the more idiomatic way of writing your query these days (since > 9.4 came out) is: > > SELECT * > FROM pg_constraint pc > LEFT JOIN LATERAL generate_series(1, case when contype in ('f','p','u') >

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

2017-01-27 Thread David G. Johnston
On Fri, Jan 27, 2017 at 5:28 AM, Rushabh Lathia wrote: > Consider the below test; > > CREATE TABLE tab ( a int primary key); > > SELECT * > FROM pg_constraint pc, > CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1, > array_upper(pc.conkey, 1)) ELSE

Re: [HACKERS] Parallel bitmap heap scan

2017-01-27 Thread Robert Haas
On Fri, Jan 27, 2017 at 1:32 AM, Dilip Kumar wrote: > There is just one line change in 0003 compared to older version, all > other patches are the same. I spent some time looking at 0001 (and how those changes are used in 0003) and I thought it looked good, so I committed

Re: [HACKERS] Proposal : For Auto-Prewarm.

2017-01-27 Thread Robert Haas
On Fri, Jan 27, 2017 at 3:18 PM, Peter Eisentraut wrote: > On 1/26/17 11:11 PM, Beena Emerson wrote: >> In that case, we could add the file location parameter. By default it >> would store in the cluster directory else in the location provided. We >> can update

Re: [HACKERS] pg_hba_file_settings view patch

2017-01-27 Thread Robert Haas
On Fri, Jan 20, 2017 at 4:01 PM, Tom Lane wrote: > * I'm not really on board with patches modifying pgindent/typedefs.list > retail. To my mind that file represents the typedefs used the last > time we pgindent'd the whole tree, and if you want an up-to-date list > you should

[HACKERS] privileges for changing schema owner

2017-01-27 Thread Peter Eisentraut
Normally, when changing the owner of an object, we check (among other things) that the new owner has the same privileges that would be needed to create the object from scratch. For for example, when changing the owner of a type, the new owner needs to have CREATE privilege on the containing

Re: [HACKERS] Proposal : For Auto-Prewarm.

2017-01-27 Thread Peter Eisentraut
On 1/26/17 11:11 PM, Beena Emerson wrote: > In that case, we could add the file location parameter. By default it > would store in the cluster directory else in the location provided. We > can update this parameter in standby for it to access the file. I don't see the need for that. -- Peter

Re: [HACKERS] Parallel Index Scans

2017-01-27 Thread Robert Haas
On Mon, Jan 23, 2017 at 1:03 AM, Amit Kapila wrote: > parallel_index_opt_exec_support_v6 - Removed the usage of > GatherSupportsBackwardScan. Expanded the comments in > ExecReScanIndexScan. I looked through this and in general it looks reasonable to me. However, I did

Re: [HACKERS] Performance improvement for joins where outer side is unique

2017-01-27 Thread Robert Haas
On Fri, Jan 27, 2017 at 2:00 PM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Jan 27, 2017 at 1:39 PM, Tom Lane wrote: >>> Um ... what's that got to do with the point at hand? > >> So I assumed from that that the issue was that

Re: [HACKERS] Performance improvement for joins where outer side is unique

2017-01-27 Thread Tom Lane
Robert Haas writes: > On Fri, Jan 27, 2017 at 1:39 PM, Tom Lane wrote: >> Um ... what's that got to do with the point at hand? > So I assumed from that that the issue was that you'd have to wait for > the first time the irrelevant-joinqual got

Re: [HACKERS] Performance improvement for joins where outer side is unique

2017-01-27 Thread Robert Haas
On Fri, Jan 27, 2017 at 1:39 PM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Jan 27, 2017 at 11:44 AM, Tom Lane wrote: >>> I'm afraid though that we may have to do something about the >>> irrelevant-joinquals issue in order for

Re: [HACKERS] pg_hba_file_settings view patch

2017-01-27 Thread Tom Lane
Haribabu Kommi writes: > On Fri, Jan 27, 2017 at 1:36 AM, Tom Lane wrote: >> It might make sense to proceed by writing a separate patch that just >> refactors the existing code to have an API like that, and then revise >> this patch to add an error

Re: [HACKERS] Performance improvement for joins where outer side is unique

2017-01-27 Thread Tom Lane
Robert Haas writes: > On Fri, Jan 27, 2017 at 11:44 AM, Tom Lane wrote: >> I'm afraid though that we may have to do something about the >> irrelevant-joinquals issue in order for this to be of much real-world >> use for inner joins. > Maybe, but it's

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

2017-01-27 Thread Robert Haas
On Fri, Jan 27, 2017 at 12:32 PM, Stephen Frost wrote: > You're completely ignoring the use-cases for which these are being done. > > I've outlined the precise use-case for pgstattuple()'s usage across the > entire database for which the admin has granted the EXECUTE access

Re: [HACKERS] pg_background contrib module proposal

2017-01-27 Thread Andrew Borodin
2017-01-27 19:14 GMT+05:00 Peter Eisentraut : > I suppose we should decide first whether we want pg_background as a > separate extension or rather pursue extending dblink as proposed elsewhere. > > I don't know if pg_background allows any use case that dblink

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

2017-01-27 Thread Dave Page
> On 27 Jan 2017, at 17:39, Stephen Frost wrote: > > Greetings, > > * Simon Riggs (si...@2ndquadrant.com) wrote: >>> On 27 January 2017 at 14:09, Dave Page wrote: On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs wrote:

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-27 Thread Christoph Berg
Re: Stephen Frost 2017-01-27 <20170127160544.gi9...@tamriel.snowman.net> > > > Uh, I figured it was more like \g, which just re-runs the last query.. > > > As in, you'd do: > > > > > > table pg_proc; % blargh, I can't read it like this > > > \G % ahh, much nicer > > > > Sure, that's exactly the

Re: [HACKERS] sequence data type

2017-01-27 Thread Peter Eisentraut
On 1/25/17 11:57 PM, Michael Paquier wrote: > @@ -15984,6 +15992,9 @@ dumpSequence(Archive *fout, TableInfo *tbinfo) > "CREATE SEQUENCE %s\n", > fmtId(tbinfo->dobj.name)); > > + if (strcmp(seqtype, "bigint") != 0) > + appendPQExpBuffer(query, "

Re: [HACKERS] Cache Hash Index meta page.

2017-01-27 Thread Robert Haas
On Thu, Jan 26, 2017 at 1:48 PM, Mithun Cy wrote: > _v11 API's was self-sustained one but it does not hold pins on the > metapage buffer. Whereas in _v12 we hold the pin for two consecutive > reads of metapage. I have taken your advice and producing 2 different >

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

2017-01-27 Thread Stephen Frost
Greetings, * Simon Riggs (si...@2ndquadrant.com) wrote: > On 27 January 2017 at 14:09, Dave Page wrote: > > On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs wrote: > > > >> If the monitoring tool requires superuser then that is a problem, so > >> it would

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

2017-01-27 Thread Stephen Frost
Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Jan 27, 2017 at 11:34 AM, Stephen Frost wrote: > > * Robert Haas (robertmh...@gmail.com) wrote: > >> OK, fair enough. get_raw_page() is clearly not something that we > >> really want everybody to have access to

Re: [HACKERS] [PATCH] Generic type subscription

2017-01-27 Thread Dmitry Dolgov
> On 24 January 2017 at 02:07, Tom Lane wrote: > I took an extremely quick look over the patch Thank you for the feedback. It took some time for me to think about all suggestions and notes. > 1. As I mentioned previously, it's a seriously bad idea that ArrayRef > is used for

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

2017-01-27 Thread Simon Riggs
On 27 January 2017 at 14:09, Dave Page wrote: > On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs wrote: > >> If the monitoring tool requires superuser then that is a problem, so >> it would be helpful if it didn't do that, please. Not much use having >> a

Re: [HACKERS] Allow interrupts on waiting standby

2017-01-27 Thread Robert Haas
On Fri, Jan 27, 2017 at 8:17 AM, Michael Paquier wrote: > There are no default clauses in the pgstat_get_wait_* routines so my > compiler is actually complaining... That's exactly WHY there are no default clauses there. :-) -- Robert Haas EnterpriseDB:

Re: [HACKERS] Performance improvement for joins where outer side is unique

2017-01-27 Thread Robert Haas
On Fri, Jan 27, 2017 at 11:44 AM, Tom Lane wrote: > I'm afraid though that we may have to do something about the > irrelevant-joinquals issue in order for this to be of much real-world > use for inner joins. Maybe, but it's certainly not the case that all inner joins are

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

2017-01-27 Thread Robert Haas
On Fri, Jan 27, 2017 at 11:34 AM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> OK, fair enough. get_raw_page() is clearly not something that we >> really want everybody to have access to by default, but if it were up >> to me, I'd change the

Re: [HACKERS] pageinspect: Hash index support

2017-01-27 Thread Robert Haas
On Tue, Jan 24, 2017 at 9:59 PM, Mithun Cy wrote: > On Thu, Jan 19, 2017 at 5:08 PM, Ashutosh Sharma > wrote: > > Thanks, Ashutosh and Jesper. I have tested the patch I do not have any > more comments so making it ready for committer. I took a

Re: [HACKERS] potential hardware donation

2017-01-27 Thread Stephen Frost
Dan, * Dan Langille (d...@langille.org) wrote: > If someone wanted to donate a SuperServer 6028TR-D72R > (http://www.supermicro.com/products/system/2U/6028/SYS-6028TR-D72R.cfm) to > the PostgreSQL project, would it be used? Possibly, but if it's really for PG infrastructure uses, the question

[HACKERS] potential hardware donation

2017-01-27 Thread Dan Langille
If someone wanted to donate a SuperServer 6028TR-D72R (http://www.supermicro.com/products/system/2U/6028/SYS-6028TR-D72R.cfm) to the PostgreSQL project, would it be used? -- Dan Langille - BSDCan / PGCon d...@langille.org

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

2017-01-27 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Simon Riggs writes: > > [ good general plan ] > > > 3. Make a list of all functions that would cause security problems. > > One by one, precisely. If we did remove all superuser checks we would > > need this list documented to

Re: [HACKERS] Performance improvement for joins where outer side is unique

2017-01-27 Thread Tom Lane
I wrote: > David Rowley writes: >> hmm. I'm having trouble understanding why this is a problem for Unique >> joins, but not for join removal? > Ah, you know what, that's just mistaken. I was thinking that we > short-circuited the join on the strength of the hash

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

2017-01-27 Thread Stephen Frost
Robert, * Robert Haas (robertmh...@gmail.com) wrote: > OK, fair enough. get_raw_page() is clearly not something that we > really want everybody to have access to by default, but if it were up > to me, I'd change the permissions check inside the function to do a > check for select privileges on

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-27 Thread Stephen Frost
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > > > I think the suggestion is that \G replaces \g (which is the same thing > > > as the semicolon). So you would do this: > > > > > > SELECT * FROM table WHERE

Re: [HACKERS] Performance improvement for joins where outer side is unique

2017-01-27 Thread Tom Lane
David Rowley writes: > On 27 January 2017 at 12:39, Tom Lane wrote: >> 2. In these same cases (unique/semi/anti joins), it is possible to avoid >> mark/restore overhead in a mergejoin, because we can tweak the executor >> logic to not require

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-27 Thread Stephen Frost
* David G. Johnston (david.g.johns...@gmail.com) wrote: > On Fri, Jan 27, 2017 at 8:31 AM, Stephen Frost wrote: > > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > > D'Arcy Cain wrote: > > > > > > > I am a pretty heavy user of psql but I don't think that that would

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-27 Thread Haribabu Kommi
On Fri, Jan 27, 2017 at 6:10 PM, Kuntal Ghosh wrote: > On Wed, Jan 25, 2017 at 6:00 PM, Haribabu Kommi > wrote: > > > Corrected as suggested. > > > > Updated patch attached. There is no change in the contrib patch. > Got whitspace error

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

2017-01-27 Thread Haribabu Kommi
On Thu, Jan 26, 2017 at 9:42 PM, Vitaly Burovoy wrote: > On 1/25/17, Haribabu Kommi wrote: > > On Wed, Jan 25, 2017 at 6:43 PM, Vitaly Burovoy < > vitaly.buro...@gmail.com> > > wrote: > > > I'm going to do (I hope) a final review tonight. >

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-27 Thread David G. Johnston
On Fri, Jan 27, 2017 at 8:31 AM, Stephen Frost wrote: > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > D'Arcy Cain wrote: > > > > > I am a pretty heavy user of psql but I don't think that that would be > so > > > helpful. I assume you mean a new option, let's call it

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-27 Thread Alvaro Herrera
Stephen Frost wrote: > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > I think the suggestion is that \G replaces \g (which is the same thing > > as the semicolon). So you would do this: > > > > SELECT * FROM table WHERE table_status = 1; % get a short list; normal > > output > > SELECT

Re: [HACKERS] pg_hba_file_settings view patch

2017-01-27 Thread Haribabu Kommi
On Fri, Jan 27, 2017 at 1:36 AM, Tom Lane wrote: > Haribabu Kommi writes: > > This patch currently doesn't have the code for reporting the two log > > messages that can occur in tokenize_file function. To support the same, > > I am thinking of

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-27 Thread Stephen Frost
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > D'Arcy Cain wrote: > > > I am a pretty heavy user of psql but I don't think that that would be so > > helpful. I assume you mean a new option, let's call it "\X" the causes the > > next query to be expanded. I type "\X" then a query. I

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-27 Thread Alvaro Herrera
D'Arcy Cain wrote: > I am a pretty heavy user of psql but I don't think that that would be so > helpful. I assume you mean a new option, let's call it "\X" the causes the > next query to be expanded. I type "\X" then a query. I realize that I made > a mistake and have to redo the query so I

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-27 Thread D'Arcy Cain
On 2017-01-27 10:05 AM, David Fetter wrote: On Fri, Jan 27, 2017 at 02:27:37PM +0100, Christoph Berg wrote: I frequently find myself in the situation that I want the "\x" expanded output mode activated just for one query. There's little wrong with typing "\x" and re-executing the query in that

Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries

2017-01-27 Thread Tom Lane
Kyotaro HORIGUCHI writes: > By the way the existing comment for the hook, >> * >> * We provide a function hook variable that lets loadable plugins get >> * control when ProcessUtility is called. Such a plugin would normally >> * call standard_ProcessUtility().

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-27 Thread David Fetter
On Fri, Jan 27, 2017 at 02:27:37PM +0100, Christoph Berg wrote: > I frequently find myself in the situation that I want the "\x" > expanded output mode activated just for one query. There's little > wrong with typing "\x" and re-executing the query in that case, but > then I'm always annoyed that

Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries

2017-01-27 Thread Tom Lane
Craig Ringer writes: > On 27 Jan. 2017 14:34, "Tom Lane" wrote: >> "The same queryString may be passed to multiple invocations of >> ProcessUtility when processing a query string containing multiple >> semicolon-separated statements; one should

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-27 Thread Christoph Berg
Re: To PostgreSQL Hackers 2017-01-27 <20170127132737.6skslelaf4txs...@msg.credativ.de> > The same idea was discussed back in 2008. Back then the outcome was > that "\x auto" was implemented, but I still think that \G is a useful > feature to have on its own, and several people in the thread seem

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

2017-01-27 Thread Robert Haas
On Fri, Jan 27, 2017 at 9:42 AM, Tom Lane wrote: > Robert Haas writes: >> The problem is if the interpretation functions aren't completely >> bulletproof, they might do things like crash the server if you use >> them to read a corrupt page. That is not

Re: [HACKERS] GSoC 2017

2017-01-27 Thread Thomas Kellerer
Greg Stark wrote > I don't think this even needs to be tied to currencies. I've often > thought this would be generally useful for any value with units. This > would prevent you from accidentally adding miles to kilometers or > hours to parsecs which is just as valid as preventing you from adding

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

2017-01-27 Thread Tom Lane
Robert Haas writes: > The problem is if the interpretation functions aren't completely > bulletproof, they might do things like crash the server if you use > them to read a corrupt page. That is not any more appealing if you > happen to be running as superuser() than

Re: [HACKERS] WIP: About CMake v2

2017-01-27 Thread Alvaro Herrera
Peter Eisentraut wrote: > Right now, however, the patch isn't moving at all, and I don't see it > going into PG10, so I'm fine with returning with feedback. There are a bunch of side patches that we should apply separately, such as the pgcrypto fix. I don't understand why they are part of this

Re: [HACKERS] pg_background contrib module proposal

2017-01-27 Thread Robert Haas
On Fri, Jan 27, 2017 at 9:14 AM, Peter Eisentraut wrote: > On 1/19/17 12:47 PM, Andrey Borodin wrote: >> 4. There is some controversy on where implemented feature shall be: in >> separate extension (as in this patch), in db_link, in some PL API, in FDW or >>

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

2017-01-27 Thread Robert Haas
On Fri, Jan 27, 2017 at 9:35 AM, Tom Lane wrote: > Robert Haas writes: >> - contrib/pageinspect has lots of superuser checks, basically because >> they have known input-validation weaknesses. See >> 3e1338475ffc2eac25de60a9de9ce689b763aced for the

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

2017-01-27 Thread Robert Haas
On Fri, Jan 27, 2017 at 8:18 AM, Simon Riggs wrote: > This is still just the Adminpack argument. This has been going on for > about a decade? Longer. Right. > If the monitoring tool requires superuser then that is a problem, so > it would be helpful if it didn't do that,

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

2017-01-27 Thread Tom Lane
Robert Haas writes: > - contrib/pageinspect has lots of superuser checks, basically because > they have known input-validation weaknesses. See > 3e1338475ffc2eac25de60a9de9ce689b763aced for the rationale in detail. FWIW, I think that's a bit of an oversimplification.

Re: [HACKERS] GSoC 2017

2017-01-27 Thread Brad DeJong
On January 27, 2017 07:08, Tom Lane wrote: > ... The things I think are unique to the currency situation are: ... Add the potential for regulatory requirements to change at any time - sort of like timezone information. So no hard coded behavior. rounding method/accuracy storage precision

Re: [HACKERS] pg_background contrib module proposal

2017-01-27 Thread Peter Eisentraut
On 1/19/17 12:47 PM, Andrey Borodin wrote: > 4. There is some controversy on where implemented feature shall be: in > separate extension (as in this patch), in db_link, in some PL API, in FDW or > somewhere else. I think that new extension is an appropriate place for the > feature. But I’m not

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

2017-01-27 Thread Robert Haas
On Thu, Jan 26, 2017 at 5:36 PM, Stephen Frost wrote: >> The first is that restricting the ability to GRANT access >> to a function, even a function that allows escalation to superuser >> privileges, doesn't improve security, because the superuser can still >> grant those

Re: [HACKERS] WIP: About CMake v2

2017-01-27 Thread Peter Eisentraut
On 1/24/17 8:37 AM, Tom Lane wrote: > Craig Ringer writes: >> Personally I think we should aim to have this in as a non default build >> mode in pg10 if it can be made ready, and aim to make it default in pg11 at >> least for Windows. > > AFAIK we haven't committed

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

2017-01-27 Thread Dave Page
On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs wrote: > On 27 January 2017 at 12:56, Dave Page wrote: > >> Probably the most common complaint I get from users >> regarding the management & monitoring tools I work on is that they >> have to use superuser

Re: [HACKERS] One-shot expanded output in psql using \G

2017-01-27 Thread Stephen Frost
Christoph, * Christoph Berg (christoph.b...@credativ.de) wrote: > The same idea was discussed back in 2008. Back then the outcome was > that "\x auto" was implemented, but I still think that \G is a useful > feature to have on its own, and several people in the thread seem to > have agreed back

Re: [HACKERS] nodes.h - comments comment

2017-01-27 Thread Tom Lane
Erik Rijkers writes: > Orthography fix in nodes.h comment block. Pushed with some further adjustments. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

[HACKERS] One-shot expanded output in psql using \G

2017-01-27 Thread Christoph Berg
I frequently find myself in the situation that I want the "\x" expanded output mode activated just for one query. There's little wrong with typing "\x" and re-executing the query in that case, but then I'm always annoyed that the expanded output is still active for the next query after that. "\x

Re: [HACKERS] Performance improvement for joins where outer side is unique

2017-01-27 Thread David Rowley
On 27 January 2017 at 12:39, Tom Lane wrote: > 2. In these same cases (unique/semi/anti joins), it is possible to avoid > mark/restore overhead in a mergejoin, because we can tweak the executor > logic to not require backing up the inner side. This goes further than > just

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

2017-01-27 Thread Simon Riggs
On 27 January 2017 at 12:56, Dave Page wrote: > Probably the most common complaint I get from users > regarding the management & monitoring tools I work on is that they > have to use superuser accounts to get the full benefits, unlike other > DBMSs where you can create a role

Re: [HACKERS] Allow interrupts on waiting standby

2017-01-27 Thread Michael Paquier
On Fri, Jan 27, 2017 at 10:35 AM, Michael Paquier wrote: > On Fri, Jan 27, 2017 at 4:36 AM, Simon Riggs wrote: >> On 26 January 2017 at 19:20, Andres Freund wrote: >>> On 2017-01-26 12:24:44 -0500, Robert Haas wrote: On

Re: [HACKERS] Performance improvement for joins where outer side is unique

2017-01-27 Thread Antonin Houska
I thought about the patch from the perspective of "grouped relations" (especially [1]). When looking for the appropriate context within the thread, I picked this message. David Rowley wrote: > On 12 March 2016 at 11:43, Tom Lane wrote: > > > >

  1   2   >