users can be found
on the wiki here: https://wiki.postgresql.org/wiki/PGLister_Announce
Once the migration of these lists is complete, an 'after' email will be
sent out.
Thanks!
Stephen
signature.asc
Description: Digital signature
Michael, Tom,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Fri, Nov 10, 2017 at 10:00 AM, Tom Lane wrote:
> > Stephen Frost writes:
> >> I'm guessing no, which essentially means that *we* consider access to
> >> lo_import/lo_export to be equivilant
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Nov 9, 2017 at 2:56 PM, Stephen Frost wrote:
> > Further, I agree entirely that we
> > shouldn't be deciding that certain capabilities are never allowed to be
> > given to a user- but that's why
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Nov 9, 2017 at 1:52 PM, Stephen Frost wrote:
> > This is not unlike the discussions we've had in the past around allowing
> > non-owners of a table to modify properties of a table, where the
> > argument
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Nov 9, 2017 at 1:16 PM, Stephen Frost wrote:
> > While we have been working to reduce the number of superuser() checks in
> > the backend in favor of having the ability to GRANT explicit rights, one
> > of the gu
ess, which is what this does and what users may start using
if we continue to remove these restrictions without providing a better
option.
Thanks!
Stephen
signature.asc
Description: Digital signature
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Each list will receive an email with a link to the wiki about the
> > migration after the list has been migrated.
>
> I suggest doing that the other way 'round. Otherwise, the email
> about
n
pgsql-general
pgsql-sql
pgsql-jobs
pgsql-novice
Nov 27 -
pgsql-announce
After -
the rest
We will be starting the migration of pgsql-www shortly.
Each list will receive an email with a link to the wiki about the
migration after the list has been migrated.
Thanks!
Stephen
o a pg_dump there to get a logical representation (and
this would test your physical database backup/restore process too...).
Thanks!
Stephen
signature.asc
Description: Digital signature
* Stephen Frost (sfr...@snowman.net) wrote:
> and we've certainly not spent effort that I've seen to try to actually
> make libpq work when multiple versions of libpq are linked into the same
> running backend.
... errr, same running application, that is, not backend
> avoid errors (Simon OP)
> >
> > 3. Implement MERGE, but without attempting to avoid concurrent ERRORs
> > (Peter)
> >
> > 4. Implement MERGE, while attempting to avoid concurrent ERRORs in
> > cases where that is possible.
> >
> > Stephen, Robert
unch of people who work on libraries all the time and carefully control
all of the versions which are installed on the OS in coordination.
Trying to do so when you can't control what's happing with the other
library strikes me as highly likely to result in a whole lot of
difficulties.
Thanks!
Stephen
signature.asc
Description: Digital signature
versed in CPU magics than I am are certainly welcome
to comment on if they think this makes sense to consider, I'm no CPU
architecture guru.
> Anyway, please don't debate the usages of the new type here. As for
> all the above plans, I admit to not having a full handle on them yet.
+1.
Thanks!
Stephen
signature.asc
Description: Digital signature
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andres Freund writes:
> > Do we care about people upgrading to unreleased versions? We could do
> > nothing, document it in the release notes, or ???
>
> Do nothing.
Agreed. Not much we can do there.
Thanks!
Stephen
sign
David,
* Stephen Frost (sfr...@snowman.net) wrote:
> * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > Since CREATE USER is officially an alias for CREATE ROLE other parts of the
> > documentation should point to CREATE ROLE, not CREATE USER. Most do but I
> > no
mean to REVOKE access to the type automatically (and what happens if you
GRANT the access back for the table..? Would we need to track that
dependency?) considering that's been the behavior for a very long time.
Thanks!
Stephen
signature.asc
Description: Digital signature
ch addresses that also, and any other
cases you find?
Thanks again!
Stephen
signature.asc
Description: Digital signature
ranted.
+1.
Barring objections, I'll commit this in a bit.
Thanks!
Stephen
signature.asc
Description: Digital signature
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 30 October 2017 at 19:55, Stephen Frost wrote:
> > I don't think MERGE should be radically different from other database
> > systems and just syntax sugar over a capability we have.
>
> I've pr
r's already explained,
both now and when he and I had exactly this same discussion years ago
when he was working on implementing INSERT .. ON CONFLICT. Time changes
many things, but I don't think anything's changed in this from the prior
discussions about it.
Thanks!
Stephen
signature.asc
Description: Digital signature
ure out how to have a completely different OS that's only
provided through your package manager, or get along with the packages
and versions as provided through the OS system (or provide your own
updated versions of the OS packages and get them installed that matches
what your packages are built against).
Thanks!
Stephen
signature.asc
Description: Digital signature
nage it properly, but later
hackers might miss that.
I would also suggest that the naming be consistent with the other bits
of the GRANT system (eg: ACL_ALL_RIGHTS_NAMESPACE would be changed to
ACL_ALL_RIGHTS_SCHEMA, to match OBJECT_SCHEMA).
I also echo the concern raised by Alvaro.
Thanks!
be possible make it work reasonably (just imagining a generic plan being
attached to pg_stat_statements with some information about if the
generic plan works well or not, blah blah, hand waving goes here).
Thanks!
Stephen
signature.asc
Description: Digital signature
rly isn't a good idea, imv.
Yes, that means that sometimes when superusers run things they get
permission denied errors. That's always been the case, and is correct.
Thanks!
Stephen
signature.asc
Description: Digital signature
pdated somehow, or similar.
> > It would also be useful for going in the reverse direction: look up
> > all the records (or just the last record) that modified a given block.
>
> Well, a LSN map is what I was suggesting.
Not sure I entirely followed what you were getting at here..?
Thanks!
Stephen
signature.asc
Description: Digital signature
to use the LSN for everything which is WAL'd. If you have
cases where that's not the case, it'd be useful to see them.
Thanks!
Stephen
signature.asc
Description: Digital signature
iscussed with barman developers is a large database
> (couple dozen of TBs should be enough) where a large fraction (say 95%)
> is read-only but there are many changes to the active part of the data,
> so that WAL is more massive than size of active data.
Yes, we've seen environments like that also.
Thanks!
Stephen
signature.asc
Description: Digital signature
eason to also
take full backups regularly.
As Alvaro notes downthread, it's also the only reasonable option
available today. It'd be great to have a better solution, and perhaps
one which summarizes the LSNs in each file would work and be better, but
that would also only be available for PG11, at the earliest.
Thanks!
Stephen
signature.asc
Description: Digital signature
th the November releases still having this issue,
I'm adding you to the CC on this thread as the one who did the freeze
visibility map work. Depending on hope here is a bit too squishy for me
when we're talking about corruption issues.
Thanks!
Stephen
signature.asc
Description: Digital signature
own
CA installed into the system global certificate store (possibly removing
certain other CAs from that set too, and distributing their own version
of the relevant package that maintains the CA set).
I agree with Magnus that most other SSL apps do default to the system
global cert store and it's generally what's expected.
Thanks!
Stephen
signature.asc
Description: Digital signature
Greetings,
* Kyotaro HORIGUCHI (horiguchi.kyot...@lab.ntt.co.jp) wrote:
> At Tue, 3 Oct 2017 10:23:08 +0900, Michael Paquier
> wrote in
>
> > On Tue, Oct 3, 2017 at 12:01 AM, Stephen Frost wrote:
> > > I certainly don't care for the idea of adding log messages
le to do in a
more formal way that minimizes the risk of getting things incorrect,
missing someone, or mis-attributing something. This all involves mostly
work on the .Org system, which we do have some folks working on now but
is also open source and it certainly wouldn't hurt to have more
essages in the logs
and I can not help but feel that this is a ridiculous amount of effort
being put into the analysis of something that *didn't* happen.
Thanks!
Stephen
signature.asc
Description: Digital signature
If it was reasonably fixable with only
small/local changes and without a catversion bump then I'd be more
inclined to keep it, but I gather from the discussion that's not the
case.
Thanks!
Stephen
signature.asc
Description: Digital signature
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 26 September 2017 at 00:42, Stephen Frost wrote:
> > That's a relatively minor point, however, and I do feel that this patch
> > is a definite improvement. Were you thinking of just applying this for
> > v1
t..? For my 2c, at least, I'm
pretty open to clarifying things in the back-branches (and we have
technically had restrictive policies for a while, they just required
using an extension, so even those pieces are relevant for older
versions, but might need additional caveats...).
Thanks!
Stephen
signature.asc
Description: Digital signature
* Magnus Hagander (mag...@hagander.net) wrote:
> On Mon, Sep 25, 2017 at 7:43 PM, Stephen Frost wrote:
> > * Satyanarayana Narlapuram (satyanarayana.narlapu...@microsoft.com) wrote:
> > > During crash recovery, last checkpoint record information is obtained
> > from the
ilt
upon should be included into core. PG is often deployed in complex
ecosystems where we need to work with other systems and this is an
important part of that.
Also, to some extent, I'm hopeful that being both open to new features,
when they make sense, and providing more ways for other systems to
work with PG, will lead to more contributions and hopefully regular
contributors who can help us maintain the code base as it continues to
grow.
Thanks!
Stephen
signature.asc
Description: Digital signature
thod has been deprecated in PG10 in
favor of the non-exclusive backup method, which avoids this by not
creating a backup label file (it's up to the backup software to store
the necessary information and create the file for use during recovery).
Please see:
https://www.postgresql.org/docs/10/sta
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Sep 19, 2017 at 01:28:11PM -0400, Stephen Frost wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > chiru r writes:
> > > > We are looking for User profiles in ope source PostgreSQL.
> > > >
al authentication system (Kerberos, for
example) which can deal with this, but I do think this is also something
we should be considering for core, especially now that we've got a
reasonable password-based authentication method with SCRAM.
Thanks!
Stephen
signature.asc
Description: Digital signature
m thinking about something like this: check if
the extension is available and, if not, skip the check of that module,
with a warning or notification that it was skipped because it wasn't
available.
Thanks!
Stephen
signature.asc
Description: Digital signature
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Fri, Sep 15, 2017 at 10:21 AM, Stephen Frost wrote:
> > No, one of the baseline requirements of pg_upgrade is to *not* screw
> > with the existing cluster. Removing its WAL or "cleaning it up"
>
ck against. amcheck is
> alphabetically first among contrib modules that have tests, IIRC.
Yes, I was working with someone earlier today who ran into exactly the
same issue. If you don't 'make world' or make the individual contrib
modules, then 'make installcheck-world' isn't going to work.
I do think it'd be nice if we could provide a better error message in
such a case..
Thanks!
Stephen
signature.asc
Description: Digital signature
actoring of little-to-never changed code, it's refactoring bits of
the system which are changed with some regularity and looks likely to
continue to need change as we add more features moving forward, and
perhaps add greater controls over process startup.
Thanks!
Stephen
signature.asc
Description: Digital signature
baseline requirements of pg_upgrade is to *not* screw
with the existing cluster. Removing its WAL or "cleaning it up"
definitely seems like it's violating that principle.
I tend to agree that it'd be good for the documentation to address this,
but this is all really getting t
If there's more than one way to do something and
they're all correct and reasonable, then I could see us choosing the
route that matches what others in the industry do, but I don't see
simply ignoring user input in this specific case as really correct and
therefore it's be
s me
as unnecessairly adding risk, should someone end up doing the wrong
command. Also, again, if I was doing this, I'd absolutely run rsync
with --dry-run for starters and review what it is going to do and make
sure that's consistent with what I'd expect.
Thanks!
Stephen
signature.asc
Description: Digital signature
Tom, all,
* Stephen Frost (sfr...@snowman.net) wrote:
> Alright, here's an updated patch which cleans things up a bit and adds
> comments to explain what's going on. I also updated the comments in
> acl.h to explain that ordering actually does matter.
Getting back to t
ll
require solving the communicate-over-the-network problem between the
primary and the replicas, which is the hard part. Whether it's an
independent utility or something built into pg_upgrade isn't really that
big of a distinction, though it doesn't seem to me like there'd b
you have to rsync both /opt/PostgreSQL/9.5 AND
> > /opt/PostgreSQL/9.6,
> > wouldn't /opt/PostgreSQL/9.6 suffice? Or does this assume "pg_upgrade
> > --link"
> > AND "rsync --hard-links" and therefore it somewhat needs to transfer less
> > data
would be nicer,
but then these options would just become "shorthand" for the generic
switch.
Thanks!
Stephen
signature.asc
Description: Digital signature
ve to register somewhere?
> >
>
> Ha, that's interesting.
>
> Should be fixed now, please try again.
Almost certainly because he hadn't logged into the commitfest app at the
time that the initial set of committers were selected, so he didn't have
an account on the CF
behaving strangely. After some debugging I found that \gx does not work if
> > you have \set FETCH_COUNT n before. Please find attached a patch that fixes
> > this incl. new regression test.
Fixed in 0cdc3e4.
Thanks for the report!
Stephen
signature.asc
Description: Digital signature
above-described topic is currently a PostgreSQL 10 open item. Stephen,
> since you committed the patch believed to have created it, you own this open
> item. If some other commit is more relevant or if this does not belong as a
> v10 open item, please let us know. Otherwise, please obser
ceholder and
then it's a pretty quick cscope to find where it's used (or another
grep, I suppose).
> Personally I'd be fine with 100 or so, but when I'm using buffers side by
> side, or when I'm working in poor conditions where I've set my terminal to
>
I'll address this on Tuesday, 8/22.
Thanks!
Stephen
signature.asc
Description: Digital signature
e above-described topic is currently a PostgreSQL 10 open item. Stephen,
> since you committed the patch believed to have created it, you own this
> open
> item. If some other commit is more relevant or if this does not belong as
> a
> v10 open item, please let us know. Otherwise, plea
s pretty unfriendly to users who
have built tools using the documentation at the time. Evidently, that
ship has sailed, however, but we didn't help things here by only
changing how PG10 works and not also at least updating the documentation
to be accurate.
I've poked Magnus..
Robert,
On Fri, Aug 4, 2017 at 23:17 Robert Haas wrote:
> On Thu, Aug 3, 2017 at 9:49 PM, Stephen Frost wrote:
> > Thanks for the patches. I'm planning to push them tomorrow morning
> > after a bit more review and testing. I'll provide an update tomorrow.
>
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Thu, Aug 3, 2017 at 4:29 AM, Stephen Frost wrote:
> > I'll provide another update tomorrow. Hopefully Michael is able to produce
> > a 9.6 patch, otherwise I'll do it.
>
> I have sent an updated version of
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Wed, Aug 2, 2017 at 7:58 PM, Stephen Frost wrote:
> > * Michael Paquier (michael.paqu...@gmail.com) wrote:
> >> Do you need a back-patchable version for 9.6? I could get one out of
> >> my pocket if ne
Tom, all,
* Stephen Frost (sfr...@snowman.net) wrote:
> This needs more cleanup, testing, and comments explaining why we're
> doing this (and then perhaps comments, somewhere.. in the backend ACL
> code that explains that the ordering needs to be preserved), but the
> basic idea
Noah,
On Tue, Aug 1, 2017 at 20:52 Noah Misch wrote:
> On Thu, Jul 27, 2017 at 10:27:36AM -0400, Stephen Frost wrote:
> > Noah, all,
> >
> > * Noah Misch (n...@leadboat.com) wrote:
> > > This PostgreSQL 10 open item is past due for your status update.
> Kindly
as you can get misled into thinking that a
> reported error must have occurred in a place you found, rather than
> someplace you didn't.
+1.
Thanks!
Stephen
signature.asc
Description: Digital signature
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Mon, Jul 31, 2017 at 9:13 PM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> On Thu, Jul 27, 2017 at 10:27 AM, Stephen Frost wrote:
> >> > * Noah Misch (n...@leadboat.com) wrote:
&
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> AFAICT, pg_dump has no notion that it needs to be careful about the order
> >> in which permissions are granted. I did
>
> > I'm afrai
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jul 27, 2017 at 10:27 AM, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
> >> This PostgreSQL 10 open item is past due for your status update. Kindly
> >> send
> >> a status update wit
27;ll get to work on the back-patch and try to draft up something to go
into the release notes for 9.6.4.
Thanks!
Stephen
signature.asc
Description: Digital signature
tor()) to generate an ACL list with an "incorrect"
ordering which would end up causing issues in older releases with
pg_dump. We've had precious little complaints from the field about this
and so, even if we were to generate such a case, I'm not sure that we'd
want to
All,
* Masahiko Sawada (sawada.m...@gmail.com) wrote:
> On Tue, Jul 25, 2017 at 4:43 AM, Michael Paquier
> wrote:
> > On Mon, Jul 24, 2017 at 6:45 PM, Stephen Frost wrote:
> >> What the change would do is make the pg_stop_backup() caller block until
> >> the las
Thom,
On Tue, Jul 25, 2017 at 20:29 Thom Brown wrote:
> On 26 July 2017 at 00:52, Stephen Frost wrote:
> > Thom,
> >
> > * Thom Brown (t...@linux.com) wrote:
> >> This is the culprit:
> >>
> >> commit 23f34fa4ba358671adab16773e79c17c92cbc870
&g
Thom,
* Thom Brown (t...@linux.com) wrote:
> This is the culprit:
>
> commit 23f34fa4ba358671adab16773e79c17c92cbc870
> Author: Stephen Frost
> Date: Wed Apr 6 21:45:32 2016 -0400
Thanks! I'll take a look tomorrow.
Stephen
signature.asc
Description: Digital signature
duced bug or not.
> However, I tried it in 9.2-9.6, and all of them produce the
> GRANTs in the right order:
>
> GRANT SELECT ON TABLE joestable TO alice WITH GRANT OPTION;
> SET SESSION AUTHORIZATION alice;
> GRANT SELECT ON TABLE joestable TO bob;
> RESET SESSION AUTH
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jul 24, 2017 at 12:31 PM, Stephen Frost wrote:
> > Those backup scripts might very well be, today, producing invalid
> > backups though, which would be much less good..
>
> True. However, I suspect that depends
> to catalog contents).
Those backup scripts might very well be, today, producing invalid
backups though, which would be much less good..
I'd hate to have to do it, but we could technically add a GUC to address
this in the back-branches, no? I'm not sure that's really worthwhile
though..
Thanks!
Stephen
signature.asc
Description: Digital signature
David,
* David Steele (da...@pgmasters.net) wrote:
> On 7/23/17 11:48 PM, Masahiko Sawada wrote:
> >On Sat, Jul 22, 2017 at 8:04 AM, Stephen Frost wrote:
> >>
> >>I started discussing this with David off-list and he'd like a chance to
> >>review it in a
Masahiko, all,
* Masahiko Sawada (sawada.m...@gmail.com) wrote:
> On Tue, Jul 18, 2017 at 1:28 PM, Stephen Frost wrote:
> > Masahiko, Michael,
> >
> > * Masahiko Sawada (sawada.m...@gmail.com) wrote:
> >> > This is beginning to shape.
> >>
> >>
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jul 20, 2017 at 3:04 PM, Stephen Frost wrote:
> > I agree that it's a common problem for VACUUM to go too fast, or for
> > VACUUM to go too slow, but that's really what the vacuum_cost_limit
> > mechanism is f
rn here,
then having a knob for that might make sense, but it sounds like the
concern here is more about the speed and less about coming up with a
reasonable way to scale the size of the ring buffer.
Of course, I'm all for coming up with a good way to size the ring
buffer, and providing a knob if we aren't able to do so, I just don't
want to add unnecessary knobs if we don't need them.
Thanks!
Stephen
signature.asc
Description: Digital signature
uffers.
I do agree that's a useful improvement to make based on your testing.
It's not clear off-hand how much that would improve this case, as
the database size appears to pretty quickly get beyond the OS memory
size (and only in the first test is the DB starting size less than
sys
ould address the case where the table is large enough
that autovacuum simply can't get through all of it before the other
backends have used all space available and then substantially increased
the size of the relation (leading to vacuum on the table running for
longer).
Thanks!
Stephen
signature.asc
Description: Digital signature
nd, on Wednesday or Thursday
of this week.
Noah,
I'll provide an update regarding this open item by COB, Thursday July
20th.
Thanks!
Stephen
signature.asc
Description: Digital signature
ion database with the comment after the tests run for that
to happen.
Thanks!
Stephen
signature.asc
Description: Digital signature
Magnus,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Sun, Jul 16, 2017 at 11:05 PM, Stephen Frost wrote:
> > I'd suggest that we try to understand why Kerberos couldn't be used in
> > that environment. I suspect in at least some cases what users would
>
her things on the web.
> >
> > I'll leave it up to Magnus and Stephen to duke it out over whether we
> > want to encourage LDAP usage, extend documentation to warn about
> > cleartext passwords with certain LDAP implementations or
> > configurations, etc etc. I'
Magnus, all,
* Magnus Hagander (mag...@hagander.net) wrote:
> (FWIW, a workaround I've applied more than once to this in AD environments
> (where kerberos for one reason or other can't be done, sorry Stephen) is to
> set up a RADIUS server and use that one as a "midd
Greetings,
* Vladimir Borodin (r...@simply.name) wrote:
> > 14 июля 2017 г., в 1:33, Stephen Frost написал(а):
> > What would be really nice for such cases is support for Kerberos and
> > delegated Kerberos credentials. Having pgpool support that would remove
> > the nee
it
> > whether there is other typos. Please review it.
>
> Thanks for providing a new version of the patch very quickly. I have
> spent some time looking at it again and testing it, and this version
> looks correct to me. Stephen, as a potential committer, would you look
>
ork with and they're happy to see we have Kerberos
but it's disappointing when they can't use Kerberos with either
connection poolers or with FDWs.
Thanks!
Stephen
signature.asc
Description: Digital signature
All,
* Noah Misch (n...@leadboat.com) wrote:
> On Fri, Jun 30, 2017 at 02:59:11PM -0400, Stephen Frost wrote:
> > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> > > On 6/30/17 04:08, Masahiko Sawada wrote:
> > > >> I'm not sure. I thi
x27;t weaken or break SCRAM to address Pgpool's needs.
I'm afraid an alternative approach will need to be considered for Pgpool
to be able to do what it does today, as I outlined in my other email.
Thanks!
Stephen
signature.asc
Description: Digital signature
...
> In short I would think that pgpool needs first to un-cheat its
> handling with MD5, which is likely here to simplify its code.
This also doesn't seem particularly relevant to me, but then again, I've
never actually looked at the pgPool code myself.
Thanks!
Stephen
signature.asc
Description: Digital signature
t;
> It's preferable to make it work. If it's not easily possible, then we
> should prohibit it.
>
> Comments from Stephen (original committer)?
I agree that it'd be preferable to make it work, but I'm not sure I can
commit to having it done in short order. I'm
, I've had cases where I would have liked to have been able to
do just exactly that. That's largely independent of this though.
Thanks!
Stephen
signature.asc
Description: Digital signature
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> On Sat, Jun 17, 2017 at 5:41 PM, Peter Eisentraut
> >> wrote:
> >>> On 6/16/17 10:51, Tom Lane wrote:
> >>>> So I&#x
nyone really
> >> seriously against that?
> >
> > I think it would be better to have it separate.
>
> +1.
+1.
Thanks!
Stephen
signature.asc
Description: Digital signature
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> On 2017/06/17 9:20, Stephen Frost wrote:
> > I think we could certainly consider if this behavior is desirable in a
> > system which includes partitioning instead of inheritance,
>
> Do we want CREATE POLICY foo O
policies to be used when a user is
accessing a table directly vs. going through the parent.
Thanks!
Stephen
signature.asc
Description: Digital signature
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Jun 15, 2017 at 07:27:55PM -0400, Stephen Frost wrote:
> > I expect the same would happen with the shell-command approach suggested
> > up-thread and the prompt-on-stdin approach too, they aren't great but I
> >
1 - 100 of 4594 matches
Mail list logo
