to 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 <t...@sss.pgh.pa.us> wrote:
> > Stephen Frost <sfr...@snowman.net> writes:
> >> I'm guessing no, which essentially means that *we* consider acce
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Nov 9, 2017 at 2:56 PM, Stephen Frost <sfr...@snowman.net> wrote:
> > Further, I agree entirely that we
> > shouldn't be deciding that certain capabilities are never allowed to be
> > given to a user- but t
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Nov 9, 2017 at 1:52 PM, Stephen Frost <sfr...@snowman.net> 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
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Nov 9, 2017 at 1:16 PM, Stephen Frost <sfr...@snowman.net> wrote:
> > While we have been working to reduce the number of superuser() checks in
> > the backend in favor of having the ability to GRANT
itrary access, 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 <sfr...@snowman.net> 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, t
gsql-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
signa
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.
Thanks!
ns only, attempting to
> > 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.
> &
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
se 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 <and...@anarazel.de> 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.
Thank
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
> >
KE 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
es 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 <sfr...@snowman.net> wrote:
> > I don't think MERGE should be radically different from other database
> > systems and just syntax sugar over a capability we have.
>
> I
d,
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
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
t 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!
Stephen
signature.
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
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
so 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
sed 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
on
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
t end up with 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
hey actually deploy systems with their 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 def
Greetings,
* Kyotaro HORIGUCHI (horiguchi.kyot...@lab.ntt.co.jp) wrote:
> At Tue, 3 Oct 2017 10:23:08 +0900, Michael Paquier
> <michael.paqu...@gmail.com> wrote in
> <cab7npqq3q1j_wbc7ypxk39do0rgvbm4-nyp2gmrcj7pfpjx...@mail.gmail.com>
> > On Tue, Oct 3, 2017 at 1
n 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 people
invo
diculous amount of effort
being put into the analysis of something that *didn't* happen.
Thanks!
Stephen
signature.asc
Description: Digital signature
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 <sfr...@snowman.net> wrote:
> > That's a relatively minor point, however, and I do feel that this patch
> > is a definite improvement. Were you thinking of just appl
ng 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 <sfr...@snowman.net> wrote:
> > * Satyanarayana Narlapuram (satyanarayana.narlapu...@microsoft.com) wrote:
> > > During crash recovery, last checkpoint record information is obta
o 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
ve backup method 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/static/c
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 <chir...@gmail.com> writes:
> > > > We are looking for User profiles in ope so
tter is to use an external 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
f
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 <sfr...@snowman.net> wrote:
> > No, one of the baseline requirements of pg_upgrade is to *not* screw
> > with the existing cluster. Removing its WAL or "clea
an installcheck 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
tle-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
the 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 to be a b
ore 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 better to reject it.
Basically, for my 2c,
oing 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 this, here'
uire 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 be much
code reuse there.
Than
ffice? Or does this assume "pg_upgrade
> > --link"
> > AND "rsync --hard-links" and therefore it somewhat needs to transfer less
> > data?
>
> As I stated above, rsync has to see _both_ hard links on the primary to
> recreate them on the standby. I thought the
it would be nicer,
but then these options would just become "shorthand" for the generic
switch.
Thanks!
Stephen
signature.asc
Description: Digital signature
ot
> > listed. Do I have 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
ving 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
-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 observe th
here I've set my terminal to
> "giant old people text" sizes, I remember the advantages of a width limit.
I wouldn't be against 100 either really, but I don't really feel all
that strongly either way. Then again, there is the back-patching pain
which would ensue to consider..
Thanks!
Stephen
signature.asc
Description: Digital signature
address this on Tuesday, 8/22.
Thanks!
Stephen
signature.asc
Description: Digital signature
n.]
>
> The 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
e
someone help with the development of better documentation in this area.
Hopefully we can get the docs in the back-branches fixed for the next
round of minor releases, and call out those updates in the release
notes, at least.
Thanks!
Stephen
signature.asc
Description: Digital signature
Robert,
On Fri, Aug 4, 2017 at 23:17 Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Aug 3, 2017 at 9:49 PM, Stephen Frost <sfr...@snowman.net> wrote:
> > Thanks for the patches. I'm planning to push them tomorrow morning
> > after a bit more review and testi
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Thu, Aug 3, 2017 at 4:29 AM, Stephen Frost <sfr...@snowman.net> 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 u
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Wed, Aug 2, 2017 at 7:58 PM, Stephen Frost <sfr...@snowman.net> wrote:
> > * Michael Paquier (michael.paqu...@gmail.com) wrote:
> >> Do you need a back-patchable version for 9.6? I could get one out of
>
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 seems
Noah,
On Tue, Aug 1, 2017 at 20:52 Noah Misch <n...@leadboat.com> 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 f
it alike, 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 <sfr...@snowman.net> wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> On Thu, Jul 27, 2017 at 10:27 AM, Stephen Frost <sfr...@snowman.net> wrote:
> >
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost <sfr...@snowman.net> 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
>
&
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jul 27, 2017 at 10:27 AM, Stephen Frost <sfr...@snowman.net> wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
> >> This PostgreSQL 10 open item is past due for your status update. Kindly
> >> send
>
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
ring 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 add all the code necessary to avoid it and then back-patch it.
Thanks!
Stephen
All,
* Masahiko Sawada (sawada.m...@gmail.com) wrote:
> On Tue, Jul 25, 2017 at 4:43 AM, Michael Paquier
> <michael.paqu...@gmail.com> wrote:
> > On Mon, Jul 24, 2017 at 6:45 PM, Stephen Frost <sfr...@snowman.net> wrote:
> >> What the change would do is make
Thom,
On Tue, Jul 25, 2017 at 20:29 Thom Brown <t...@linux.com> wrote:
> On 26 July 2017 at 00:52, Stephen Frost <sfr...@snowman.net> wrote:
> > Thom,
> >
> > * Thom Brown (t...@linux.com) wrote:
> >> This is the culprit:
> >>
> >>
Thom,
* Thom Brown (t...@linux.com) wrote:
> This is the culprit:
>
> commit 23f34fa4ba358671adab16773e79c17c92cbc870
> Author: Stephen Frost <sfr...@snowman.net>
> Date: Wed Apr 6 21:45:32 2016 -0400
Thanks! I'll take a look tomorrow.
Stephen
signature.asc
Description: Digital signature
r this is a newly introduced 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;
> RES
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jul 24, 2017 at 12:31 PM, Stephen Frost <sfr...@snowman.net> wrote:
> > Those backup scripts might very well be, today, producing invalid
> > backups though, which would be much less good..
>
> True. Howe
would require a change
> 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 <sfr...@snowman.net> wrote:
> >>
> >>I started discussing this with David off-list and he'd like a chance to
> &g
Masahiko, all,
* Masahiko Sawada (sawada.m...@gmail.com) wrote:
> On Tue, Jul 18, 2017 at 1:28 PM, Stephen Frost <sfr...@snowman.net> 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 <sfr...@snowman.net> 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
> &g
e 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
ee 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
system memory to begin with).
Th
uld 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
nesday 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
fter 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 <sfr...@snowman.net> 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
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'll add th
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 "middle man&
Greetings,
* Vladimir Borodin (r...@simply.name) wrote:
> > 14 июля 2017 г., в 1:33, Stephen Frost <sfr...@snowman.net> написал(а):
> > What would be really nice for such cases is support for Kerberos and
> > delegated Kerberos credentials. Having pgpool support that w
t patch and I've checked 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, w
ey'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 t
en 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
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
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 happy to work to prohibit
it, but i
iked 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 <sfr...@snowman.net> writes:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> On Sat, Jun 17, 2017 at 5:41 PM, Peter Eisentraut
> >> <peter.eisentr...@2ndquadrant.com> wrote:
> >>> O
de under src/tools/ in our main repo. Is anyone 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 f
ed 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
> > exp
1 - 100 of 4526 matches
Mail list logo
