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 index
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
===
pos
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 a plugin would normally
>> * call standard_ProcessUti
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 confusion.
A lot of people apparently cons
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
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 plpytho
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 surely
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?
--
Pet
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 primary key);
> create
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 upthread.
> You'll see that one o
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 r
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 to make it defer c
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 consented to renaming pg_xlog with the
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 not touch even one of their A
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 think
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
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 one with a commit bit.
>
> I think
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
app
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 (pgsql-hackers@postgres
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 obviously).
>>
>> Thanks for the review.
>
> Why not u
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 as
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 storing those changing requ
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 De
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 ready, and aim to make it default in pg11 at
>>> least for Windows
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 there are no default clauses there. :-)
And that
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 code to have an API like that, and then revise
> >> this patch to
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 havi
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 basica
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
<
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 nonetheless, in a way that can be surprising.
>>>
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 output functions for the dataty
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 th
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 PostgreSQL Company
--
Sent v
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')
>
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 NULL END AS int) AS position;
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 0001.
--
Robert Haas
E
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 this parameter in standby for it to
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 ask the buildfarm.
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 schema
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 Ei
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 notice one thing that I thi
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 you'd have to wait for
>> the first time the irrelevant-joinqual
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 satisfied before the
> optimization kicked in.
No,
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 this to be of much real-world
>>> use for inner joins.
>
>> May
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 message field to the per-line struct. Or
>> may
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 certainly not the case that all inner joins a
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 in.
> I've not yet seen
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 can't
> handle (yet).
pg_background in
> 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:
If the monitoring tool requires superuser then that is a prob
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 s
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, "
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
> patches.
Hmm. I think both of th
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 be helpful if it didn't do that, please. Not
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 by default, but if it
> 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 both array subscript
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 cool tool if it don't work with the server.
>
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: http://www.enterprisedb.com
The Enterpri
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 highly
selective. There
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 permissions check inside the
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 look at this patch. I think hash_page_items() is b
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
s
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
* 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 advise people of the risks, s
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 (or merge) quals
> only, but actu
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 th
* 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 tab
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 backing up the inner side.
> I've made modifications
* 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 be
> > so
> > > > help
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 warning while applying contrib_macaddr8_1.patch:184.
>
Cor
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.
> Please, remove initialization of the variables "d" and
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 "\X" the
> causes th
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
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 changing line_nums list to line_info list that can
>
* 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 realiz
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 hav
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 c
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().
>> */
> This is quite a matter of
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 t
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 use pstmt->stmt_location and
>> pstmt->stmt_len to i
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 t
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 any more appealing if you
>> happen to be r
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
>
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 otherwise.
I'm not aware tha
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 p
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
>> somewhere else. I think that new exte
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 rationale in detail.
>
> FWIW, I think that's a
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, please. Not much use hav
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. There are two
components to
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
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 c
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 privileges with more work
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 to accepting this at all, let a
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 accounts to get the full benefits, unlike oth
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 th
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:
http://www.postgresql.org/mailpref/pgsql
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 a
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 tweaking the executor l
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 with just the requir
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 Thu, Jan 26, 2017 at 7:18 AM, Simon Riggs wrote:
> Currently a wa
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:
> >
> > It seems like the major intellectual complexity her
1 - 100 of 128 matches
Mail list logo
