On Mon, May 18, 2015 at 5:44 PM, Uriy Zhuravlev u.zhurav...@postgrespro.ru
wrote:
On Monday 18 May 2015 10:21:10 Tom Lane wrote:
There are fairly significant reasons why we have not done this, based
on the difficulty of updating existing cached plans that might have
incidentally depended
Hello Hackers.
I have attached a patch that extends ALTER OPERATOR to support COMMUTATOR,
NEGATOR, RESTRICT and JOIN. This patch is based on master. It is small patch
with regression tests.
Why do it?
The operator has four important parameters that can be set only during the
creation. These
On Monday 18 May 2015 10:21:10 Tom Lane wrote:
There are fairly significant reasons why we have not done this, based
on the difficulty of updating existing cached plans that might have
incidentally depended on those operator properties during creation.
Perhaps it's all right to simply ignore
Uriy Zhuravlev u.zhurav...@postgrespro.ru writes:
I have attached a patch that extends ALTER OPERATOR to support COMMUTATOR,
NEGATOR, RESTRICT and JOIN.
There are fairly significant reasons why we have not done this, based
on the difficulty of updating existing cached plans that might have
On Sun, May 17, 2015 at 9:41 PM, Josh Berkus j...@agliodbs.com wrote:
Is there a particular reason why + makes more sense as shallow
concatination and || makes more sense as deep concatination? Like,
something in JS or other client languages which would make that
preference make more sense
On Sat, May 16, 2015 at 12:21:12PM -0400, Noah Misch wrote:
The rest of this change is opaque to me. More consistent with what? The
old use of the tli variable sure looked like a bug, considering the variable
was never set to anything but zero. What is the anticipated behavior change?
The
On 5/17/15 10:58 PM, Josh Berkus wrote:
The goal here was stated to preventing authentication misconfiguration
by shortsighted admins who have superuser access and the ability to
change pg_hba.conf. This is tantamount to giving someone a gun and
bullets, but expecting duct tape across the
On 05/18/2015 08:17 AM, Andrew Dunstan wrote:
On 05/17/2015 09:08 PM, Peter Geoghegan wrote:
On Sun, May 17, 2015 at 8:04 AM, Andrew Dunstan and...@dunslane.net
wrote:
Sure. I thought we'd covered this but it's possible that we didn't,
or that
it got rebroken. There have been complaints
Andrew Gierth and...@tao11.riddles.org.uk writes:
Incidentally, the most obvious obstacle to better planning of grouping
sets in the sorted cases is not so much how to pick paths in
grouping_planner itself, but rather the fact that query_planner wants to
be given only one sort order. Is there
On 05/18/2015 12:11 AM, Peter Geoghegan wrote:
On Sun, May 17, 2015 at 8:41 PM, Josh Berkus j...@agliodbs.com wrote:
Is there a particular reason why + makes more sense as shallow
concatination and || makes more sense as deep concatination? Like,
something in JS or other client languages
Peter Geoghegan p...@heroku.com writes:
I came up with a simple approach to conveniently attaching a debugger
when a bug manifested itself from within the regression tests, by
patching Postgres. This worked quite well. The backend would look for
the occurrence of a magical token within each
On 05/17/2015 09:08 PM, Peter Geoghegan wrote:
On Sun, May 17, 2015 at 8:04 AM, Andrew Dunstan and...@dunslane.net wrote:
Sure. I thought we'd covered this but it's possible that we didn't, or that
it got rebroken. There have been complaints about the limitation on values
containing jbvBinary,
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Hrm, ok. So for the near future, we should leave it more or less
as-is? We don't have a timescale yet, but it's our intention to
submit a hashagg support patch for grouping sets as soon as time
permits.
Tom Well, mumble. I keep saying that I
Hello,
Er, I am not sure I follow here. The idea proposed was to define a
string formatted with some infra-language within the existing GUC
s_s_names.
I am sorry, I misunderstood. I thought the language approach meant use of
hooks and module.
As you mentioned the first step would be to
18.05.2015, 06:41, Josh Berkus kirjoitti:
On 05/17/2015 05:46 PM, Robert Haas wrote:
On May 17, 2015, at 8:38 PM, Peter Geoghegan p...@heroku.com wrote:
The current behavior does not seem acceptable for the concatenate
operator (operator || jsonb).
I don't agree. It seems pretty clear to me
2015-05-18 15:15 GMT+09:00 Denis Kirjanov k...@itsirius.su:
- Ursprüngliche Mail -
Von: Kohei KaiGai kai...@kaigai.gr.jp
An: Robert Haas robertmh...@gmail.com
CC: David G. Johnston david.g.johns...@gmail.com, Denis Kirjanov
k...@itsirius.su, pgsql-hackers@postgresql.org, Kohei
On 2015/05/16 3:46, Robert Haas wrote:
On Thu, May 14, 2015 at 4:07 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
The attached patch adds missing NO INHERIT to the CHECK clause in the
synopsis section in the reference page on CREATE FOREIGN TABLE.
Good catch. Committed.
Thanks for
On 2015-05-18 PM 05:03, Etsuro Fujita wrote:
On 2015/05/16 3:32, Robert Haas wrote:
On Thu, May 14, 2015 at 6:37 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
On second thought, I noticed that as for this option, we cannot live without
allowing IMPORT FOREIGN SCHEMA to return ALTER
- Ursprüngliche Mail -
Von: Kohei KaiGai kai...@kaigai.gr.jp
An: Robert Haas robertmh...@gmail.com
CC: David G. Johnston david.g.johns...@gmail.com, Denis Kirjanov
k...@itsirius.su, pgsql-hackers@postgresql.org, Kohei KaiGai
kai...@ak.jp.nec.com
Gesendet: Samstag, 16. Mai 2015 03:32:55
On 05/18/2015 06:35 AM, Josh Berkus wrote:
On 05/15/2015 05:58 AM, Bruce Momjian wrote:
I have processed all the open email items I can through mid-March,
though I do have two pg_upgrade fixes pending application today. I will
continue processing doc fixes and major bug fixes for 9.5, but
On 05/16/2015 12:42 AM, Jim Nasby wrote:
On 5/14/15 6:30 PM, Heikki Linnakangas wrote:
On 05/15/2015 02:28 AM, Heikki Linnakangas wrote:
I think this is now ready for committing, but I'm pretty tired now so
I'll read through this one more time in the morning, so that I won't
wake up to a red
On 2015/05/16 3:32, Robert Haas wrote:
On Thu, May 14, 2015 at 6:37 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
On second thought, I noticed that as for this option, we cannot live without
allowing IMPORT FOREIGN SCHEMA to return ALTER FOREIGN TABLE statements
because we cannot declare
On Sun, May 17, 2015 at 09:31:47PM +0200, José Luis Tallón wrote:
On 05/17/2015 07:39 PM, Tom Lane wrote:
=?windows-1252?Q?Jos=E9_Luis_Tall=F3n?= jltal...@adv-solutions.net writes:
On the other hand, ISTM that what we all intend to achieve is some
Postgres equivalent of the SUID bit... so why
On 05/18/2015 11:36 AM, Jim Nasby wrote:
On 5/17/15 10:58 PM, Josh Berkus wrote:
The goal here was stated to preventing authentication misconfiguration
by shortsighted admins who have superuser access and the ability to
change pg_hba.conf. This is tantamount to giving someone a gun and
The MSVC members of the buildfarm seem to not like my recent patch
b14cf229f4bd7238, which basically did this to contrib/hstore_plpython's
Makefile:
SHLIB_LINK += ../hstore/libhstore.a $(wildcard
../../src/pl/plpython/libpython*.a) $(wildcard
../../src/pl/plpython/libplpython*.a)
endif
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Marko Tiikkaja wrote:
Any chance to get this fixed in time for 9.1.16?
I hope you had pinged some days earlier. Here's a patch, but I will
wait until this week's releases have been tagged before pushing.
Is this a recent regression, or has it
On 2015-05-18 14:13:51 -0300, Alvaro Herrera wrote:
Hmm, AFAICS the problematic check was introduced by this commit:
commit 9f1e051adefb2f29e757cf426b03db20d3f8a26d
Author: Alvaro Herrera alvhe...@alvh.no-ip.org
Date: Fri Nov 29 11:26:41 2013 -0300
so it isn't hot off the oven, but it
My goal there was to further improve group commit. When running pgbench
-j10 -c10, it was common to see fsyncs that alternated between flushing 1
transaction, and 9 transactions. Because the first one to the gate would
go
through it and slam it on all the others, and it would take one
On 05/18/2015 01:05 PM, Tom Lane wrote:
Meh. You could also add select pg_backend_pid() or some such.
But really, the way I generally do this is to run gdb via a script
that auto-attaches to the right postgres process if at all possible.
Removes the whole problem.
This should go on the
Andrew Dunstan and...@dunslane.net writes:
On 05/18/2015 12:48 PM, Tom Lane wrote:
Looking at vcregress.pl's sub fetchRegressOpts, it seems that it only
notices REGRESS_OPTS = lines not REGRESS_OPTS += lines, so that
isn't surprising --- but how is it that the tests *are* still loading
On 18 May 2015 at 12:59, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Marko Tiikkaja wrote:
Any chance to get this fixed in time for 9.1.16?
I hope you had pinged some days earlier. Here's a patch, but I will
wait until this week's releases have
Andres Freund wrote:
On 2015-05-18 14:13:51 -0300, Alvaro Herrera wrote:
Hmm, AFAICS the problematic check was introduced by this commit:
commit 9f1e051adefb2f29e757cf426b03db20d3f8a26d
Author: Alvaro Herrera alvhe...@alvh.no-ip.org
Date: Fri Nov 29 11:26:41 2013 -0300
so it
I wrote:
If I were to fix fetchRegressOpts so it picks up all the makefile's
additions to REGRESS_OPTS, would we be able to eliminate that hack?
Or do we need the python-version kluge anyway?
Oh, scratch that, there's no very easy way to deal with the ifeq()
business in the makefile. So I'll
On Mon, May 18, 2015 at 5:05 AM, Andrew Dunstan and...@dunslane.net wrote:
As between || and + I'm personally moderately indifferent. I think you're
representing some body of understanding about the effects of certain
operators as being widespread when that's very far from clear.
You really
On 05/18/2015 01:18 PM, Peter Geoghegan wrote:
So I think we should use the + operator to distance this from the
hstore concatenate operator, which *is* widely understood to be mostly
useful for nested assignment.
Having trouble scanning this. Since hstore isn't nested what the heck
does
On Mon, May 18, 2015 at 6:44 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Geoghegan p...@heroku.com writes:
I came up with a simple approach to conveniently attaching a debugger
when a bug manifested itself from within the regression tests, by
patching Postgres. This worked quite well. The
On 05/18/2015 01:37 PM, Tom Lane wrote:
I wrote:
If I were to fix fetchRegressOpts so it picks up all the makefile's
additions to REGRESS_OPTS, would we be able to eliminate that hack?
Or do we need the python-version kluge anyway?
Oh, scratch that, there's no very easy way to deal with the
On Mon, May 18, 2015 at 10:29 AM, Andrew Dunstan and...@dunslane.net wrote:
Having trouble scanning this. Since hstore isn't nested what the heck does
nested assignment mean w.r.t. hstore?
It means assigning to one subdatum in the hstore datum, as opposed
to simply assigning an entirely new
On Mon, May 18, 2015 at 8:41 AM, Ryan Pedela rped...@datalanche.com wrote:
On Sun, May 17, 2015 at 9:41 PM, Josh Berkus j...@agliodbs.com wrote:
Is there a particular reason why + makes more sense as shallow
concatination and || makes more sense as deep concatination? Like,
something in JS
On Sun, May 17, 2015 at 08:35:49PM -0700, Josh Berkus wrote:
On 05/15/2015 05:58 AM, Bruce Momjian wrote:
I have processed all the open email items I can through mid-March,
though I do have two pg_upgrade fixes pending application today. I will
continue processing doc fixes and major bug
Marko Tiikkaja wrote:
Hi hackers,
Any chance to get this fixed in time for 9.1.16?
I hope you had pinged some days earlier. Here's a patch, but I will
wait until this week's releases have been tagged before pushing.
I checked 9.2, and it doesn't look like it's subject to the same
problem:
On 5/18/15 8:44 AM, Tom Lane wrote:
Peter Geoghegan p...@heroku.com writes:
I came up with a simple approach to conveniently attaching a debugger
when a bug manifested itself from within the regression tests, by
patching Postgres. This worked quite well. The backend would look for
the
On Sat, May 16, 2015 at 01:05:27PM -0400, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Sat, May 16, 2015 at 5:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
With feature freeze behind us, I'd like to propose that now is a good
time for a pgindent run.
+1, except I suggest
Bruce Momjian wrote:
On Sun, May 17, 2015 at 09:31:47PM +0200, José Luis Tallón wrote:
On 05/17/2015 07:39 PM, Tom Lane wrote:
=?windows-1252?Q?Jos=E9_Luis_Tall=F3n?= jltal...@adv-solutions.net
writes:
On the other hand, ISTM that what we all intend to achieve is some
Postgres
On 2015-05-18 12:59:47 -0400, Tom Lane wrote:
If the former, maybe we should take the risk of fixing it today
(the patch certainly looks safe enough). But if it's been this
way a long time and nobody noticed till now, I'd agree with waiting.
It's a old regression, and nobody noticed it until
On 5/17/15 10:35 PM, Josh Berkus wrote:
On 05/15/2015 05:58 AM, Bruce Momjian wrote:
I have processed all the open email items I can through mid-March,
though I do have two pg_upgrade fixes pending application today. I will
continue processing doc fixes and major bug fixes for 9.5, but
Jim Nasby jim.na...@bluetreble.com writes:
On 5/18/15 8:44 AM, Tom Lane wrote:
If your approach involves modifying a target query in a regression test,
it really seems unnecessary to do all this. Just insert something like
select pg_sleep(60) into the test script before the target query.
A
creates the specified path if it does not exist. Does it?
No, jsonb_replace() doesn't create an element, if it doesn't exist. I
think, otherwise it can be confusing, so probably jsonb_add() may be more
appropriate (and, actually, this function was already mentioned in previous
discussions).
On
On May 12, 2015 4:13 PM, Stephen Frost sfr...@snowman.net wrote:
* Magnus Hagander (mag...@hagander.net) wrote:
On Tue, May 12, 2015 at 3:21 PM, Stephen Frost sfr...@snowman.net
wrote:
* Magnus Hagander (mag...@hagander.net) wrote:
We could also use the category that we have now, or
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Marko Tiikkaja wrote:
Any chance to get this fixed in time for 9.1.16?
I hope you had pinged some days earlier. Here's a patch, but I will
wait until this week's releases have been tagged before pushing.
Is this a
On 05/18/2015 12:48 PM, Tom Lane wrote:
The MSVC members of the buildfarm seem to not like my recent patch
b14cf229f4bd7238, which basically did this to contrib/hstore_plpython's
Makefile:
SHLIB_LINK += ../hstore/libhstore.a $(wildcard
../../src/pl/plpython/libpython*.a) $(wildcard
On 05/18/2015 01:43 PM, Peter Geoghegan wrote:
On Mon, May 18, 2015 at 10:29 AM, Andrew Dunstan and...@dunslane.net wrote:
Having trouble scanning this. Since hstore isn't nested what the heck does
nested assignment mean w.r.t. hstore?
It means assigning to one subdatum in the hstore datum,
On 05/17/2015 09:11 PM, Peter Geoghegan wrote: As I said, I don't think
that my preference for deep concatenation is
a matter of taste. I think that shallow concatenation is fundamentally
and objectively at odds with what jsonb is supposed to be (as long as
concatenation is the way nested
On Sun, May 17, 2015 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Rather than adding tlists per se to Paths, I've been vaguely toying with
a notion of identifying all the interesting subexpressions in a query
(expensive functions, aggregates, etc), giving them indexes 1..n, and then
marking
On Mon, May 18, 2015 at 11:24 AM, Josh Berkus j...@agliodbs.com wrote:
On 05/17/2015 09:11 PM, Peter Geoghegan wrote: As I said, I don't think
that my preference for deep concatenation is
a matter of taste. I think that shallow concatenation is fundamentally
and objectively at odds with what
On 05/18/2015 11:34 AM, Peter Geoghegan wrote:
I'm not necessarily attached to +. I just want to make this
different to hstore's || operator. There should be a similar idiom
with jsonb, but that can come later.
This argument still makes no sense to me. Hstore is not nested. If
anything, the
Robert Haas robertmh...@gmail.com writes:
On Sun, May 17, 2015 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Rather than adding tlists per se to Paths, I've been vaguely toying with
a notion of identifying all the interesting subexpressions in a query
(expensive functions, aggregates, etc),
On 05/17/2015 08:58 PM, Josh Berkus wrote:
You've added exactly one additional step in their way, and not a
particularly difficult one. It simply doesn't solve the problem you're
trying to solve, which is unsurprising, because technology has never
been able to solve the problem of
On Mon, May 18, 2015 at 11:16 AM, Andrew Dunstan and...@dunslane.net wrote:
I could argue at least as convincingly that what the jsonb || operator does
is exactly analogous to what hstore's || does.
Again, my concern is not primarily a theoretical one. It's primarily a
practical concern. We are
On 05/18/2015 02:45 PM, Josh Berkus wrote:
On 05/18/2015 11:34 AM, Peter Geoghegan wrote:
I'm not necessarily attached to +. I just want to make this
different to hstore's || operator. There should be a similar idiom
with jsonb, but that can come later.
This argument still makes no sense to
On Mon, May 18, 2015 at 11:45 AM, Josh Berkus j...@agliodbs.com wrote:
On 05/18/2015 11:34 AM, Peter Geoghegan wrote:
I'm not necessarily attached to +. I just want to make this
different to hstore's || operator. There should be a similar idiom
with jsonb, but that can come later.
This
On 05/18/2015 11:58 AM, Peter Geoghegan wrote:
As you say, hstore isn't nested, and so this simply doesn't come up
there. We have failed to adopt || to jsonb in a way that makes
sense. We should have adopted it to jsonb in exactly the same way as
the @ operator was.
OK, you've flagellated
On 18 May 2015 at 14:50, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, May 17, 2015 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Rather than adding tlists per se to Paths, I've been vaguely toying with
a notion of identifying all the interesting
On Mon, May 18, 2015 at 12:12 PM, Josh Berkus j...@agliodbs.com wrote:
OK, you've flagellated this deceased equine enough that I'm calling the
ASPCA. I get that you're unhappy that we don't have deep append.
Everyone gets this. I simply don't care; shallow append is better than
no append at
On 05/18/2015 08:36 AM, Jim Nasby wrote:
On 5/17/15 10:58 PM, Josh Berkus wrote:
The goal here was stated to preventing authentication misconfiguration
by shortsighted admins who have superuser access and the ability to
change pg_hba.conf. This is tantamount to giving someone a gun and
On Mon, May 18, 2015 at 5:58 AM, Josh Berkus j...@agliodbs.com wrote:
Let's say we offered a compile-time option, and then someone built a
package postgresql-9.6-secureauth.deb. So, your lazy admin is having
trouble debugging an auth problem and wants to set trust. But they
can't. So they
Simon Riggs si...@2ndquadrant.com writes:
On 18 May 2015 at 14:50, Tom Lane t...@sss.pgh.pa.us wrote:
So for the moment, let's assume that we still rigidly follow the sequence
of upper-level steps currently embodied in grouping_planner. (I'm not
sure if it even makes sense to consider other
On Mon, May 18, 2015 at 2:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't know, but it seems like this might be pulling in the opposite
direction from your previously-stated desire to get subquery_planner
to output Paths rather than Plans as soon as possible.
Sorry, I didn't mean to suggest
On Mon, May 18, 2015 at 09:32:23PM +0200, Volker Aßmann wrote:
That's what we are currently doing with the patch Bernd posted at the
beginning
of this thread. But we thought we might post the patch for consideration here
as the use case might be sufficiently general that it may be of use to
Bruce Momjian wrote:
On Mon, May 18, 2015 at 09:32:23PM +0200, Volker Aßmann wrote:
But I like the more general approach proposed by Alvaro, so in case this
patch
would have a chance to not be immediately rejected, I would try to implement
the more generic approach. I would also include
On Mon, May 18, 2015 at 05:00:41PM -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
On Mon, May 18, 2015 at 09:32:23PM +0200, Volker Aßmann wrote:
But I like the more general approach proposed by Alvaro, so in case this
patch
would have a chance to not be immediately rejected, I
On 05/18/2015 03:21 PM, Peter Geoghegan wrote:
The only question worth discussing is whether we change the operator to
+ (or, for that matter, something else). I've seen your vote on this,
so, does anyone else have an opinion on + vs. ||? Preferably with a
justification with some kind of
On Mon, May 18, 2015 at 3:21 PM, Peter Geoghegan p...@heroku.com wrote:
What is hard to understand about that?
What is hard to understand is why you're going on and on about what is
basically a matter of opinion after several people have said they
don't agree with your opinion.
Realistically,
On Mon, May 18, 2015 at 12:24 PM, Josh Berkus j...@agliodbs.com wrote:
On 05/18/2015 08:57 AM, Ryan Pedela wrote:
If not, deep concatenation would solve this problem, but I can also see
another solution. Use + for shallow concatenation since it really means
add element to top-level path as
On 05/18/2015 01:04 PM, Ryan Pedela wrote:
Let me back up a little. I always like to think about what is the ideal
interface first and then worry about implementation because
implementation can always be changed but interface can't. I think the
current concat/merge interface is the ideal. It
On Mon, May 18, 2015 at 1:19 PM, Catalin Iacob iacobcata...@gmail.com wrote:
In hstore @ means unnested containment, in jsonb it means nested
containment. Therefore, when an hstore operator is applied to jsonb it gets
nestedness as jsonb is nested and adds that nestedness is an important
thing
Bruce Momjian wrote:
I have processed all the open email items I can through mid-March,
though I do have two pg_upgrade fixes pending application today. I will
continue processing doc fixes and major bug fixes for 9.5, but
everything else I do will be for 9.6.
Thanks, Bruce.
Just so we're
On Mon, May 18, 2015 at 9:03 PM Andrew Dunstan and...@dunslane.net wrote:
So you're arguing that we shouldn't call the operation in question ||
because it's pretty much the same, mutatis mutandis, as the hstore
operation of the same name. You've lost me.
Hopefully this helps. Peter's
On Tue, May 12, 2015 at 3:16 PM, Andres Freund and...@anarazel.de wrote:
Could you rebase and adjust your patch? I'd rather have the inference
structure refactoring separate.
I realized that I didn't split out the patch as requested.
Here is a cumulative version of what was previously posted.
On 2015-05-18 22:10, Josh Berkus wrote:
On 05/18/2015 01:04 PM, Ryan Pedela wrote:
In the context of splitting shallow and deep merge into two operators, I
think + is better for shallow and || better for deep. The reason for +
is because many programming languages have this behavior. If I see
Simon Riggs wrote:
On 15 May 2015 at 19:03, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Andres Freund wrote:
Alternatively we could make MultiXactIdIsRunning() return false 9.3
when in recovery. I think that'd end up fixing things, but it seems
awfully fragile to me.
Hm,
On Mon, May 18, 2015 at 1:03 PM, Robert Haas robertmh...@gmail.com wrote:
Realistically, as much as we might try to fool ourselves into
believing otherwise, operators are not self-documenting, except for
the ones you knew by the fourth grade. People will have to read the
documentation no
On May 18, 2015, at 3:32 PM, Volker Aßmann volker.assm...@gmail.com wrote:
I know these measures won't protect against an experienced attacker who gains
root access, but hope it slows them down sufficiently so the admins may have
a chance to detect the attack.
It won't.
...Robert
--
Sent
On 2015-05-18 19:59:29 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On 2015-05-18 19:23:59 -0400, Tom Lane wrote:
Hm, just forcing a collation and restricting the input to ascii should
work, right?
I think that's fragile as can be. Is there a *really really* good
On Mon, May 18, 2015 at 2:09 PM, Peter Geoghegan p...@heroku.com wrote:
You pointed out that the reason for this trivial bug on Jabber, but
here's the obvious fix, including an EXPLAIN regression test.
Also, I attach a patch adding ruleutils.c deparsing support for INSERT
statement target
Andres Freund and...@anarazel.de writes:
On 2015-05-18 23:22:33 -0400, Tom Lane wrote:
I'm inclined to think I should revert b82a7be603f1811a and instead make
the seclabel provider columns use text_pattern_ops. That would fix
their collation problem with less of a backwards compatibility
On Tue, May 19, 2015 at 11:41 AM, Andres Freund and...@anarazel.de wrote:
On 2015-05-19 11:34:49 +0900, Michael Paquier wrote:
+1 for moving it at least 1 month.
2015-06-15 also collides with pgcon, which probably isn't the best
idea. I do think we should try hard doing a triage at the start
Andres Freund and...@anarazel.de writes:
On 2015-05-18 19:59:29 -0400, Tom Lane wrote:
I think that's fragile as can be.
Hm. I think actually just forcing a collation would bring this on-par
with name, right? We don't have any guarantees about the contents of
e.g. pg_database.datname being
On 2015-05-18 23:22:33 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On 2015-05-18 19:59:29 -0400, Tom Lane wrote:
I think that's fragile as can be.
Hm. I think actually just forcing a collation would bring this on-par
with name, right? We don't have any guarantees
On May 18, 2015, at 10:41 PM, Andres Freund and...@anarazel.de wrote:
On 2015-05-19 11:34:49 +0900, Michael Paquier wrote:
+1 for moving it at least 1 month.
2015-06-15 also collides with pgcon, which probably isn't the best
idea. I do think we should try hard doing a triage at the start of
On 2015-05-18 23:34:16 -0400, Robert Haas wrote:
On May 18, 2015, at 10:41 PM, Andres Freund and...@anarazel.de wrote:
[first 9.6 CF around 2015-07-15]
Honestly, that seems awful soon. I would have thought maybe August 15th.
Maybe we should just rename it to 9.6-1 for now? And then look
On 2015-05-19 11:34:49 +0900, Michael Paquier wrote:
+1 for moving it at least 1 month.
2015-06-15 also collides with pgcon, which probably isn't the best
idea. I do think we should try hard doing a triage at the start of a CF
and not many with experience in the project are going to have time
On 05/18/2015 04:54 PM, David G. Johnston wrote:
On Mon, May 18, 2015 at 12:12 PM, Josh Berkus j...@agliodbs.com
mailto:j...@agliodbs.comwrote:
On 05/18/2015 11:58 AM, Peter Geoghegan wrote:
As you say, hstore isn't nested, and so this simply doesn't come up
there. We have
On Mon, May 18, 2015 at 1:53 AM, Robert Haas robertmh...@gmail.com wrote:
On May 17, 2015, at 11:04 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Sun, May 17, 2015 at 7:45 AM, Robert Haas robertmh...@gmail.com
wrote:
crazy-ideaI wonder if we could write WAL to two different files in
On Mon, May 18, 2015 at 7:11 AM, Andrew Dunstan and...@dunslane.net wrote:
Here's an patch along those lines. It seems to do the trick, at least for
your test case, and it has the merit of being very small, so small I'd like
to backpatch it - accepting jbvBinary as is in pushJsonbValue seems
Michael Paquier michael.paqu...@gmail.com writes:
On Tue, May 19, 2015 at 11:41 AM, Andres Freund and...@anarazel.de wrote:
On 2015-05-19 11:34:49 +0900, Michael Paquier wrote:
There are many remaining open items.
At least on https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items
there
On 2015-05-18 23:30:20 -0400, Tom Lane wrote:
Michael Paquier michael.paqu...@gmail.com writes:
On Tue, May 19, 2015 at 11:41 AM, Andres Freund and...@anarazel.de wrote:
On 2015-05-19 11:34:49 +0900, Michael Paquier wrote:
There are many remaining open items.
At least on
Andres Freund and...@2ndquadrant.com writes:
On 2015-02-25 12:08:32 -0500, Tom Lane wrote:
Andrew Gierth and...@tao11.riddles.org.uk writes:
So while helping someone with an unrelated issue, I did a quick query to
look for collation-dependent indexes, and was rather shocked to find
that not
On Mon, May 18, 2015 at 07:10:00PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote:
(BTW, one practical issue is where would we get typedef lists relevant
to the back branches. I'm not sure if the buildfarm
* Andres Freund (and...@anarazel.de) wrote:
On 2015-05-18 19:59:29 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
Hm, just forcing a collation and restricting the input to ascii should
work, right?
I think that's fragile as can be.
Hm. I think actually just
1 - 100 of 126 matches
Mail list logo
