Tom Lane wrote:
multi-object DROP IF NOT EXISTS would fail to perform as expected.
Surely this would be a noop :-)
cheers
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> Ok Here it is:
> -Moves CheckDropPermissions and friends from utility.c to aclchk.c
> (pg_drop_permission_check)
> -Makes all the Remove* functions take a DropStmt *, they each do their
> own foreach() loop and permission checks
Applied with revisions.
On Thu, Jun 12, 2008 at 5:35 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> So that's leading me to lean towards keeping RemoveRelation
> et al where they are and distributing the work currently done in
> ProcessUtility out to them. This sounds duplicative, but about all that
> really is there to dupli
On Thu, Jun 12, 2008 at 5:35 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>> Yep, I thought about doing the reverse. Namely Just passing the
>> DropStmt to RemoveRelation(s). But then all the permission check
>> functions are in utility.c. Splitting those
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> Yep, I thought about doing the reverse. Namely Just passing the
> DropStmt to RemoveRelation(s). But then all the permission check
> functions are in utility.c. Splitting those out seemed to be about
> the same as splitting out all the ObjectAddress
On Thu, Jun 12, 2008 at 11:58 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I don't really like the patch though; it seems kind of a brute force
> solution. You've got ProcessUtility iterating through a list of objects
> and doing a little bit of work on each one, and then making a new list
> that Rem
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Alex Hunsaker escribió:
>> I'm not proposing this patch for actual submission, more of a would this
>> work?
>> If I'm not missing something glaring obvious Ill go ahead and make the
>> rest of the Remove things behave the same way
> I don't think ther
On Thu, Jun 12, 2008 at 11:35 AM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> I don't think there's anything wrong with that in principle. However,
> does your patch actually work? The changes in expected/ is unexpected,
> I think.
Yeah I thought they looked a bit odd at first to. I thought it w
Alex Hunsaker escribió:
> Ok I'm obviously missing something important... Why not Just make the
> various Remove* functions take a list?
>
> I'm not proposing this patch for actual submission, more of a would this work?
> If I'm not missing something glaring obvious Ill go ahead and make the
> re
On Wed, Jun 11, 2008 at 4:07 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Agreed --- I committed what I had, anyone want to volunteer for
> refactoring the execution of DropStmt?
Sure! see the attached patch...
> After looking again, I think that this is not technically very
> difficult, but coming
Tom Lane wrote:
> After looking again, I think that this is not technically very
> difficult, but coming up with something that looks tasteful to everyone
> might be tricky. In particular I didn't see a nice way to do it without
> using struct ObjectAddress in a bunch of header files that don't
>
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ... I wonder if it would
>> be worth refactoring the code so that a multiple-object DROP is
>> implemented via performMultipleDeletions(). This would have more
>> than just cosmetic advantages: it would no longer matter what
>> order
Tom Lane wrote:
> One particular case of interest is in truncate.out, where the
> table-at-a-time implementation of DROP TABLE is clearly exposed
> by the fact that you get multiple NOTICEs. I wonder if it would
> be worth refactoring the code so that a multiple-object DROP is
> implemented via p
There was some discussion a few days ago about making dependency.c emit
dependency reports in the same style that pg_shdepend.c does, viz
a lot of DETAIL lines on a single message instead of separate NOTICE
messages. Attached is a tentative patch that does that. See the
regression-test diffs for
14 matches
Mail list logo
