Re: [GENERAL] dropping role w/dependent objects - Mailing list pgsql-patches

From Alvaro Herrera
Subject Re: [GENERAL] dropping role w/dependent objects
Date
Msg-id 20070502125153.GB4585@alvh.no-ip.org
Whole thread Raw
In response to Re: [GENERAL] dropping role w/dependent objects  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Tom Lane wrote:
> "Ed L." <pgsql@bluepolka.net> writes:
> > [ enlarge MAX_REPORTED_DEPS to 2000 ]
>
> I was about to apply this, but stopped to reflect that it is probably
> not such a hot idea.  My concern is that enormously long error message
> detail fields are likely to break client software, particularly GUI
> clients.  A poor (e.g., truncated) display isn't unlikely, and a crash
> not entirely out of the question.  Moreover, who's to say that 2000 is
> enough lines to cover all cases?  And if it's not, aren't you faced with
> an even bigger problem?
>
> Perhaps a better solution is to keep MAX_REPORTED_DEPS where it is, and
> arrange that when it's exceeded, the *entire* list of dependencies gets
> reported to the postmaster log; we can expect that that will work.
> We still send the same just-the-count message to the client.  We could
> add a hint suggesting to look in the postmaster log for the details.
> This would require some refactoring of checkSharedDependencies's API,
> I suppose, but doesn't seem especially difficult.

Actually I was thinking that we could report MAX_REPORTED_DEPS (the
original value) dependencies to the client log, and finish with "and
other N dependencies not shown here".  Maybe we could mix both solutions
and send a partial report to the client and a full report to the server
log.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

pgsql-patches by date:

Previous
From: NikhilS
Date:
Subject: Re: CREATE TABLE LIKE INCLUDING INDEXES support
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] autovacuum does not start in HEAD