* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 1/18/17 8:25 AM, Stephen Frost wrote:
> > I was actually thinking about it the other way- start out by changing
> > them to both be 5m and then document next to checkpoint_timeout (and
> > max_wal_size, perha
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Wed, Jan 18, 2017 at 10:35 AM, Michael Paquier
> wrote:
> > On Wed, Jan 18, 2017 at 7:31 AM, Stephen Frost wrote:
> >> Perhaps we need a way for pg_ctl to realize a cold-standby case and
> >> throw
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Wed, Jan 18, 2017 at 7:31 AM, Stephen Frost wrote:
> > Perhaps we need a way for pg_ctl to realize a cold-standby case and
> > throw an error or warning if --wait is specified then, but that hardly
> > seem
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jan 17, 2017 at 4:46 PM, Stephen Frost wrote:
> >> But what if we're restarting after, say, rebooting? Then there's
> >> nobody to see the progress messages, perhaps. The system just seems
> >> to
* Robert Haas (robertmh...@gmail.com) wrote:
> I'm OK with continuing to use "xlog" as the user-facing name for the
> write-ahead log, and I am OK with switching to wal. But leaving
> things in the halfway in-between state where they are right now seems
> like a mess. It conveniences the people w
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jan 17, 2017 at 11:27 AM, Peter Eisentraut
> wrote:
> > On 1/15/17 11:40 PM, Fujii Masao wrote:
> >> This change may confuse the users who run "pg_ctl start" to perform a crash
> >> recovery, archive recovery and standby server (with hot_stand
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Here's an updated version of the RLS planning patch that gets rid of
> >> the incorrect interaction with Query.hasRowSecurity and adjusts
> &g
Peter,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 1/13/17 10:18 AM, Stephen Frost wrote:
> > Certainly, check_postgres is going to have to be changed to address this
> > and, unsurprisingly, it's already had to address a variety of major
> > ver
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 1/12/17 2:22 PM, Stephen Frost wrote:
> > The point I was making above is that the only reason to not make such
> > changes is if they really are entirely arbitrary, but I don't think
> > we'd even be
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 1/12/17 1:40 PM, Stephen Frost wrote:
> > I just don't buy this argument, at all. These functions names are
> > certainly not the only things we're changing with PG10 and serious
> > monitoring/
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On January 12, 2017 10:50:18 AM PST, Stephen Frost wrote:
> >* Andres Freund (and...@anarazel.de) wrote:
> >> On 2017-01-12 13:40:50 -0500, Stephen Frost wrote:
> >> > * Jim Nasby (jim.na...@bluetreble.com) wr
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I just don't buy this argument, at all. These functions names are
> > certainly not the only things we're changing with PG10 and serious
> > monitoring/backup/administration tools are almost cert
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-01-12 13:40:50 -0500, Stephen Frost wrote:
> > * Jim Nasby (jim.na...@bluetreble.com) wrote:
> > > The way I see it, either one person can spend an hour or whatever
> > > creating an extension once, or every po
Jim,
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> The way I see it, either one person can spend an hour or whatever
> creating an extension once, or every postgres install that's using
> any of these functions now has yet another hurdle to upgrading.
I just don't buy this argument, at all. Th
Josh,
* Josh Berkus (j...@agliodbs.com) wrote:
> For that reason, as of today, I am stepping down from the PostgreSQL
> Core Team.
I'm sure you'll hear this a lot, but:
Thank you.
Your leadership as a member of core and your focus on advocacy has
definitely helped this community and project mov
Ashutosh,
* Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> On Tue, Jan 10, 2017 at 10:18 AM, Stephen Frost wrote:
> > For reasons which seem likely to be entirely unintentional, pg_restore
> > will accept a '-1' for -j:
> >
> > pg_restore -j -
Fabien,
* Fabien COELHO (coe...@cri.ensmp.fr) wrote:
> >I think we need to focus on things that _can't_ be done first, rather
> >than things that require porting, e.g. until we had savepoints, you
> >couldn't migrate an application that needed it. It wasn't a question of
> >porting --- there was
Ashutosh,
* Stephen Frost (sfr...@snowman.net) wrote:
> Attached patch adds the same check to pg_restore that's in pg_dump
> already. Looks like it should back-patch to 9.3 pretty cleanly and I'll
> add a similar check for 9.2.
After playing with this, it seems entirely
Ashutosh,
* Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> On Tue, Jan 10, 2017 at 10:18 AM, Stephen Frost wrote:
> > For reasons which seem likely to be entirely unintentional, pg_restore
> > will accept a '-1' for -j:
> >
> > pg_restore -j -
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Tue, Jan 10, 2017 at 8:03 PM, Robert Haas wrote:
>
> > On Mon, Jan 9, 2017 at 11:02 AM, Peter Eisentraut
> > wrote:
> > > On 1/9/17 7:44 AM, Magnus Hagander wrote:
> > >> So based on that, I suggest we go ahead and make the change t
Greetings,
For reasons which seem likely to be entirely unintentional, pg_restore
will accept a '-1' for -j:
pg_restore -j -1
This seems to result in the parallel state being NULL and so things
don't outright break, but it hardly seems likely to be what the user was
asking for- my guess is that
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-01-04 09:38:42 -0500, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > On 2017-01-03 10:37:08 -0500, Stephen Frost wrote:
> > > > * Vladimir Rusinov (vrusi...@google.com) wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jan 5, 2017 at 11:56 AM, Stephen Frost wrote:
> >> One thing I'm kind of happy about is that, as far as I can see, there
> >> hasn't been much backlash against the existing ALTER SYSTEM, either
> >>
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jan 4, 2017 at 3:30 PM, Tom Lane wrote:
> > Simon Riggs writes:
> >> My next thought is ALTER SYSTEM support for pg_hba.conf, especially
> >> since that would make it easier to do a formal test of Haribabu's
> >> pg_hba view patch
Tomas,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On 01/05/2017 02:23 PM, Magnus Hagander wrote:
> >It's easy enough to construct a benchmark specifically to show the
> >difference, but of any actual "normal workload" for it. Typically the
> >optimization applies to things like bulk lo
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 1/4/17 10:57 AM, Tom Lane wrote:
> > I still maintain that the existing solution for passphrases is useless,
> > but in the interest of removing objections to the current patch, I'll
> > go make that happen.
>
> Sounds good.
Agreed
* Andreas Karlsson (andr...@proxel.se) wrote:
> On 01/04/2017 04:14 PM, Stephen Frost wrote:
> >* Andreas Karlsson (andr...@proxel.se) wrote:
> >>A possible solution might be to only add the error throwing hook
> >>when loading certificates during SIGHUP (and at Windows
* Andreas Karlsson (andr...@proxel.se) wrote:
> On 01/04/2017 03:48 PM, Magnus Hagander wrote:
> >On Wed, Jan 4, 2017 at 3:47 PM, Tom Lane >It does not; what would be the point, if the key would be lost at
> >SIGHUP?
> >
> >If we lost it, yes. But we could keep the old key around if it has
* Magnus Hagander (mag...@hagander.net) wrote:
> On Wed, Jan 4, 2017 at 3:47 PM, Tom Lane wrote:
> > Magnus Hagander writes:
> > > On Tue, Jan 3, 2017 at 4:54 PM, Tom Lane wrote:
> > >> I think probably the right thing for now is to install a do-nothing
> > >> callback, so that at least we don't
Ashutosh,
I realize you were replying to yourself, but you probably didn't need to
include the entire thread below or to top-post.
* Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> 1. pg_explain_plan_time_v3 adds SUMMARY option which behaves as:
> SUMMARY when ON prints planning time. W
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-01-03 10:37:08 -0500, Stephen Frost wrote:
> > * Vladimir Rusinov (vrusi...@google.com) wrote:
> > > I think I +1 on this.
> > > I've did a github search on these function names and there is a lot of
* Magnus Hagander (mag...@hagander.net) wrote:
> On Tue, Jan 3, 2017 at 4:54 PM, Tom Lane wrote:
>
> > Magnus Hagander writes:
> > > On Tue, Jan 3, 2017 at 4:02 AM, Tom Lane wrote:
> > >> Before we leave this area, though, there is a loose end that requires
> > >> more thought. That is, what a
* Vladimir Rusinov (vrusi...@google.com) wrote:
> On Tue, Jan 3, 2017 at 3:37 PM, Stephen Frost wrote:
> > If they're maintained, then they'll be updated. I don't have any
> >
> sympathy if they aren't maintained.
> >
>
> Updating may be non-tri
Vladamir, all,
* Vladimir Rusinov (vrusi...@google.com) wrote:
> On Tue, Jan 3, 2017 at 11:56 AM, Michael Paquier
> wrote:
>
> > Yeah, let's make the life of users just easier if we can, without any
> > extension. Some people are likely going to forget to enable it anyway,
> > and some more don'
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Fri, Dec 30, 2016 at 8:08 PM, Vladimir Rusinov wrote:
> > Now, I'm not sure whether it is worth maintaining function aliases. Assuming
> > these are indeed trivial (can somebody point me to example?) I see roughly
> > the same amount of dow
Cynthia,
Please don't top-post on the PG mailing lists but rather write responses
in-line.
* Cynthia Shang (cynthia.sh...@crunchydata.com) wrote:
> I have never heard of coding standards where naming conventions required a
> function/variable name match a directory or file name. It seems that wo
Cynthia,
* Cynthia Shang (cynthia.sh...@crunchydata.com) wrote:
> 1) I agree with Michael that we should make this change backward compatible.
> It would help PostgreSQL image if we did not break everyone's code. It costs
> businesses money to rewrite code (e.g. middle tier software, backup tool
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> I think it's an awful choice of name; it has nothing to do with either
> >> the functionality or the printed name of the field.
>
> >
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> >>> I am not sure whether using *summary* to print just planning time is a
> >>> good idea. Another option could be SUMMARY_PLAN_T
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>
> > > The only functional issue might be the removal of the IsA() checks. If
> > > we don't cast any Node before passing it to
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Peter Eisentraut wrote:
> > Here is a small cleanup patch to make more use of the RoleSpec
> > struct/node throughout the parser to avoid casts and make the code more
> > self-documenting.
>
> This makes sense to me. I started to do this at som
* Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> >> One can use this option as
> >> postgres=# explain (summary on) select * from pg_class c, pg_type t
> >> where c.reltype = t.oid;
> >> QUERY PLAN
> >> -
Gilles, all,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Gilles Darold (gilles.dar...@dalibo.com) wrote:
> > Added to next commitfest. To explain more this patch, the completion of
> > SQL command:
> >
> > ALTER DEFAULT PRIVILEGES FOR ROLE xxx [tab]
>
&g
Ashutosh,
* Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> We report planning and execution time when EXPLAIN ANALYZE is issued.
> We do not have facility to report planning time as part EXPLAIN
> output. In order to get the planning time, one has to issue EXPLAIN
> ANALYZE which involv
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> In practice, there should never be waits on LWLocks (much less spinlocks)
> that exceed order-of-milliseconds; if there are, either we chose the wrong
> lock type or the system is pretty broken in general. So maybe it's
> sufficient if we provide a wa
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Joel Jacobson writes:
> > We already have xact_start, query_start and backend_start
> > to get the timestamptz for when different things happened.
>
> > I would like to propose adding a fourth such column, "waiting_start",
> > which would tell how long tim
Amit,
* Amit Langote (amitlangot...@gmail.com) wrote:
> On Fri, Dec 23, 2016 at 12:07 AM, Stephen Frost wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> (Of course, maybe the question we ought to be asking here is why
> >> ATTACH/DETACH PARTITION failed t
's no point in making the user have
to pick one when they're tab-completing. Of course, we still accept
both and if the user chooses to write out 'for user', we will handle
that correctly and continue the tab completion beyond that.
Thanks!
Stephen
From 1f7eb8473d40497b67cc30b4
Gilles,
* Gilles Darold (gilles.dar...@dalibo.com) wrote:
> Le 20/11/2016 à 15:46, Gilles Darold a écrit :
> > When tab-completing after ALTER DEFAULT PRIVILEGES ... GRANT|REVOKE,
> > currently psql injects completion from the GRANT|REVOKE order, rather
> > than the one expected.
> >
> > A patch i
Artur,
* Artur Zakirov (a.zaki...@postgrespro.ru) wrote:
> 2016-12-21 20:34 GMT+03:00 Stephen Frost :
> > Did you happen to look at adding a regression test for this to
> > test_ddl_deparse?
>
> Of course. I updated the patch.
I added a few comments and back-patched
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alvaro Herrera writes:
> >> I had considered removing those but thought that some users might think
> >> that they're only "altering" one table and therefore felt it made sense
> >> to keep those explicitly listed.
>
> > I agree with Stephen; it's not crys
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> So maybe something like
> >>
> >> All the forms of ALTER TABLE that act on a single table,
> >> except RENAME and SET SCHEMA,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> So maybe something like
>
> All the forms of ALTER TABLE that act on a single table,
> except RENAME and SET SCHEMA, can be combined into a
> list of multiple alterations to be applied together.
Committed and back-patch'd that way.
Thank
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > That's a good point, we might be doing things wrong in other places in
> > the code by using FirstNormalObjectId on pre-8.1 servers.
>
> > What I suggest then is an independent patch which uses
Andrea,
* Andrea Urbani (matfan...@mail.com) wrote:
>I had a problem with a Postgresql 9.3.5 on 32 bit linux, old 2.6.26
>kernel:
Ok, though, to be clear, this is a feature request, so we wouldn't
back-patch adding this to pg_dump.
>I have solve it adding two new parameters, --custom
Artur,
* Artur Zakirov (a.zaki...@postgrespro.ru) wrote:
> 2016-11-19 21:28 GMT+03:00 Michael Paquier :
> > On Thu, Nov 17, 2016 at 1:17 PM, Alvaro Herrera
> > wrote:
> >> It's a bug. You're right that we need to handle the object class
> >> somewhere. Perhaps I failed to realize that tsconfigs
David,
* David Fetter (da...@fetter.org) wrote:
> On Tue, Dec 20, 2016 at 06:14:40PM -0500, Stephen Frost wrote:
> > * David Fetter (da...@fetter.org) wrote:
> > > On Tue, Dec 20, 2016 at 08:34:19AM -0500, Stephen Frost wrote:
> > > > * Heikki Linnakangas (hlinn...
David,
* David Fetter (da...@fetter.org) wrote:
> On Tue, Dec 20, 2016 at 08:34:19AM -0500, Stephen Frost wrote:
> > * Heikki Linnakangas (hlinn...@iki.fi) wrote:
> > > Even if you have a separate "verifier type" column, it's not fully
> > > normalized,
Heikki,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> Even if you have a separate "verifier type" column, it's not fully
> normalized, because there's still a dependency between the verifier
> and verifier type columns. You will always need to look at the
> verifier type to make sense of the ver
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Sat, Dec 17, 2016 at 5:42 AM, Stephen Frost wrote:
> > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> >> On 12/15/16 8:40 AM, Stephen Frost wrote:
> >> > I don't follow why we
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 12/15/16 8:40 AM, Stephen Frost wrote:
> > I don't follow why we can't change the syntax for CREATE USER to allow
> > specifying the verifier type independently.
>
> That's what the last patch
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > That's a good point, we might be doing things wrong in other places in
> > the code by using FirstNormalObjectId on pre-8.1 servers.
>
> > What I suggest then is an independent patch which uses
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 12/14/2016 04:57 PM, Stephen Frost wrote:
> >* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> >>On 12/14/16 5:15 AM, Michael Paquier wrote:
> >>>I would be tempted to suggest adding the verifier type as
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Tom Lane wrote:
>
> > Thinking about this, I'm wondering what is the connection between
> > what psql does and what should be in the SGML (or XML) docs, anyway.
> > Nobody says boo when we have to do s/ > to put it in the docs; why is s
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> The real problem here, IMO, is the break in expected regression outputs.
> The previous thread mainly discussed that in terms of its impact on
> third-party tests using pg_regress, but for our own purposes it would be
> just as nasty to need to adjust
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 12/14/16 12:03 PM, Stephen Frost wrote:
> > If we do want to change that, perhaps we should also change psql to not
> > output the trailing whitespace in the first place..?
>
> Previous discussion:
> ht
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 14 December 2016 20:12:05 EET, Bruce Momjian wrote:
> >On Wed, Dec 14, 2016 at 11:27:15AM +0100, Magnus Hagander wrote:
> >> I would so like to just drop support for plain passwords completely
> >:) But
> >> there's a backwards compatibility issue
* Vladimir Rusinov (vrusi...@google.com) wrote:
> I'm not sure if it makes sense to merge just these, as it will not help
> people with whitespace-eating editors.
I think we've established that it's going to be quite a while before we
will reach a point where whitespace-eating editors aren't a pro
* Vladimir Rusinov (vrusi...@google.com) wrote:
> They are considered bad practice in many style guides and many editors
> configured to stip them on every save.
>
> Such editors will produce spurious diffs when editing the documentation.
>
> Therefore, I propose this patch.
As mentioned down-th
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > If we do want to change that, perhaps we should also change psql to not
> > output the trailing whitespace in the first place..?
>
> Yeah, maybe. I seem to recall having looked at that a long time ago
&
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Vladimir Rusinov writes:
> > Therefore, I propose this patch.
>
> Right now is a really bad time to do that; what it will mostly accomplish
> is to break back-patching of doc fixes for little benefit.
>
> There is work afoot to convert the documentation t
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 12/14/16 5:15 AM, Michael Paquier wrote:
> > I would be tempted to suggest adding the verifier type as a new column
> > of pg_authid
>
> Yes please.
This discussion seems to continue to come up and I don't entirely
understand why w
Andres, all,
* Andres Freund (and...@anarazel.de) wrote:
> I'm wondering if it's not time for $subject:
> - V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was
> forgotten
> - They have us keep weird hacks around just for the sake of testing V0
> - they actually cost performance, be
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> (Actually, the most likely way in which this would break things is if
> >> it started causing built-in casts to get dumped ... have you checked?)
>
&g
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Ok, thinking a bit more on this and testing, it looks like we record the
> > initdb-defined casts as 'pinned' in pg_depend all the way back to 7.3.
> > Therefore, we could use that as the gatin
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> I have a vague feeling that the code for dumping casts and/or transforms
> >> may have some assumptions that the underlying function is also being
>
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Dec 8, 2016 at 2:11 PM, Stephen Frost wrote:
> > Yes, that makes the compiler warning go away.
>
> Great, pushed.
Awesome, thanks!
> > ... your compiler knows that key->partnatts will always be >= 1?
>
>
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Dec 8, 2016 at 1:49 PM, Stephen Frost wrote:
> > * Robert Haas (rh...@postgresql.org) wrote:
> >> Implement table partitioning.
> >
> > My compiler apparently doesn't care for this:
> >
&g
* Robert Haas (rh...@postgresql.org) wrote:
> Implement table partitioning.
My compiler apparently doesn't care for this:
.../src/backend/catalog/partition.c: In function ‘partition_rbound_cmp’:
.../src/backend/catalog/partition.c:1787:13: warning: ‘cmpval’ may be used
uninitialized in this func
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> I have a vague feeling that the code for dumping casts and/or transforms
> >> may have some assumptions that the underlying function is also being
>
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > As pointed out by Peter E, this also impacts CASTs. Attached is a patch
> > which addresses both by simply also pulling any functions which are
> > referenced from pg_cast or pg_transform when they
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> Hmm, I had mixed feeling about what to do about that as well. So now, we
> have the description of various new features buried into VI. Reference
> section of the documentation, which is simply meant as a command
> reference. I agree
All,
* Stephen Frost (sfr...@snowman.net) wrote:
> While testing pg_dump, I discovered that there seems to be an issue when
> it comes to TRANSFORMs.
[...]
As pointed out by Peter E, this also impacts CASTs. Attached is a patch
which addresses both by simply also pulling any functions
Michael, all,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Wed, Dec 07, 2016 at 03:42:53PM +0300, Aleksander Alekseev wrote:
> > > In the same host, primary and standby will try to use the tablespace
> > > in the same path. That's the origin of this breakage.
> >
> > Sorry, I don't f
All,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 12/6/16 9:53 PM, Tom Lane wrote:
> > I think we should give serious consideration to back-patching commit
> > ecb0d20a9, which changed the default semaphore type to unnamed-POSIX
> > on Linux.
>
> Even with that change, dynami
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Dec 6, 2016 at 3:23 PM, Stephen Frost wrote:
> > Given the lack of screaming, I'll push the attached in a bit, which just
> > initializes the two variables being complained about. As mentioned,
> > ther
All,
* Stephen Frost (sfr...@snowman.net) wrote:
> Not sure if anyone else has been seeing these, but I'm getting a bit
> tired of them. Neither is a live bug, but they also seem pretty simple
> to fix. The attached patch makes both of these warnings go away. At
> least fo
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On 2016-12-05 20:51:02 +0000, Stephen Frost wrote:
> > Add support for restrictive RLS policies
> This is missing a catversion bump.
Ewps, apologies and thanks for pointing it out.
Fixed.
Stephen
signature.asc
Descript
* Stephen Frost (sfr...@snowman.net) wrote:
> Updated patch attached.
Erp, actually attached this time.
Thanks again!
Stephen
From 27e5fdac801cecc5ac33daccf979bbc59458dbbc Mon Sep 17 00:00:00 2001
From: Stephen Frost
Date: Thu, 1 Sep 2016 02:11:30 -0400
Subject: [PATCH] Add support
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> This note reads a little awkwardly to me. I think I would write it as:
>
> Note that ALTER POLICY only allows the set of roles
> to which the policy applies and the USING and
> WITH CHECK expressions to be modified. To change
>
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> 2016-12-05 16:23 GMT+01:00 Stephen Frost :
> > * Pavel Stehule (pavel.steh...@gmail.com) wrote:
> > > I found some crazy queries in one customer application. These queries are
> > > stupid, but it was surprise f
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> I found some crazy queries in one customer application. These queries are
> stupid, but it was surprise for me so there are not some simple optimization
>
> create table foo(a int);
> insert into foo select generate_series(1,10);
> ana
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> On Mon, Dec 5, 2016 at 11:56 AM, Michael Paquier
> wrote:
> > On Mon, Dec 5, 2016 at 2:50 PM, Haribabu Kommi
> > wrote:
> >> I definitely may missed judging the current state of the patch. Please feel
> >> free to update the actual status.
> >
> >
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andres Freund writes:
> > This:
>
> >> Discussion:
> >> https://postgr.es/m/20161128182113.6527.58...@wrigleys.postgresql.org
> >> Discussion:
> >> https://postgr.es/m/CA+renyUEE29=X01JXdz8_TQvo6n9=2xoebbrnq8rklyr+kj...@mail.gmail.com
>
> > still looks
All,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I think this is a straw man. We've already decided to use message-IDs
> as the basic identity of messages for this purpose; other proposals
> were considered before and rejected as too inconvenient.
I tend to agree with Tom on this, for better or wor
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 1 December 2016 at 14:38, Stephen Frost wrote:
> > * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> >> In get_policies_for_relation() ...
> >> ... I think it should sort the restrictive policies by name
>
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 30 November 2016 at 21:54, Stephen Frost wrote:
> > Unless there's further comments, I'll plan to push this sometime
> > tomorrow.
>
> Sorry I didn't have time to look at this properly. I was inten
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> Hmm. I've not read any of the new code yet, but the fact that this
> test now reduces to a one-time filter makes it effectively useless as
> a test of qual evaluation order because it has deduced that it doesn't
> need to evaluate them. I wo
* Stephen Frost (sfr...@snowman.net) wrote:
> * Jeevan Chalke (jeevan.cha...@enterprisedb.com) wrote:
> > 4. It will be good if we have an example for this in section
> > "5.7. Row Security Policies"
>
> I haven't added one yet, but will plan to do so.
I
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> Perhaps, it should say something like:
>
> All the actions except RENAME, SET TABLESPACE (when using the ALL IN
> TABLESPACE form) and SET SCHEMA can be combined into a list of multiple
> alterations to apply in parallel.
Seems like t
501 - 600 of 4446 matches
Mail list logo
