2016-07-21 13:53 GMT+09:00 Alvaro Herrera :
> Satoshi Nagayasu wrote:
>> Hi,
>>
>> I have been trying MADlib [1], a machine-learning library for PostgreSQL,
>> and when I was tying it on 9.5 and 9.6beta2, I often got following
>> error on my box.
>>
>>
>> madpac
Satoshi Nagayasu wrote:
> Hi,
>
> I have been trying MADlib [1], a machine-learning library for PostgreSQL,
> and when I was tying it on 9.5 and 9.6beta2, I often got following
> error on my box.
>
>
> madpack.py : ERROR : SQL command failed:
> SQL: DROP OWNED
Hi,
I have been trying MADlib [1], a machine-learning library for PostgreSQL,
and when I was tying it on 9.5 and 9.6beta2, I often got following
error on my box.
madpack.py : ERROR : SQL command failed:
SQL: DROP OWNED BY madlib_19_installcheck CASCADE;
ERROR:
Adrian Klaver writes:
> I am not sure I am following. Are we talking two different cases here?
What I was pointing out was that the non-superuser case seems to be
broken almost completely, whereas the superuser case is only broken
if the object owner has given away some grant options and those ha
Adrian Klaver writes:
> On 02/08/2013 08:14 AM, Tom Lane wrote:
>> Of course, postgres has other options besides that, of which "DROP OWNED
>> BY ak02" is probably the most appropriate here. Or if you really want
>> to get rid of just that grant, SET ROLE TO akretschmer01 and revoke.
> The DROP
I found one other problem in this area, which was that REASSIGN OWNED
didn't work real well either after I changed serial sequences'
dependency type to AUTO. What I did about it was to make
shdepReassignOwned call ATExecChangeOwner with recursing = true,
which suppresses all those tedious error ch
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What I'm considering is this: scan pg_shdepend looking for objects to
> delete, and save them into a list; but each time we find one, we also
> find objects that depend on it. Those dependent objects should be
> ignored; but we should also remove from t
Tom Lane wrote:
> I think a correct solution probably requires making a list of all
> objects to delete by scanning pg_shdepend and then starting to
> delete 'em, using the list as "oktodelete" context similar to the
> way that dependency.c handles auto/internal objects.
What I'm considering is t
Tom Lane wrote:
> I think a correct solution probably requires making a list of all
> objects to delete by scanning pg_shdepend and then starting to
> delete 'em, using the list as "oktodelete" context similar to the
> way that dependency.c handles auto/internal objects.
Hum. I'll take a look at
So I was fooling with making serial sequences be auto rather than internal
dependencies of their columns, and the regression tests blew up on me:
*** ./expected/dependency.out Mon Nov 21 07:49:33 2005
--- ./results/dependency.outSat Aug 19 17:46:55 2006
***
*** 109,113
--- 1
On Sat, Aug 13, 2005 at 10:09:35AM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I'm working on the promised DROP OWNED patch, and just noticed that it
> > needs modifications to the Grant/Revoke machinery that are too invasive
> > to consider for 8.1; the problem is that
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I'm working on the promised DROP OWNED patch, and just noticed that it
> needs modifications to the Grant/Revoke machinery that are too invasive
> to consider for 8.1; the problem is that ExecuteGrantStmt takes textual
> names for objects and grantees, a
Definitely should be released without it ... it is an extension not
submitted for inclusion prior to the feature freeze ...
On Fri, 12 Aug 2005, Alvaro Herrera wrote:
I'm working on the promised DROP OWNED patch, and just noticed that it
needs modifications to the Grant/Revoke machinery that
I'm working on the promised DROP OWNED patch, and just noticed that it
needs modifications to the Grant/Revoke machinery that are too invasive
to consider for 8.1; the problem is that ExecuteGrantStmt takes textual
names for objects and grantees, and what I have from pg_shdepend are
Oids. Dropping
14 matches
Mail list logo
