Gregory Stark <stark@enterprisedb.com> writes:
> On the other hand the fact that we don't actually provide an
> exhaustive set of data for that purpose and a) nobody's complained and
> b) it's for basically the same reason that you're suggesting this
> change, ie, that it isn't convenient and isn't important enough to go
> out of our way to build just for that purpose could mean it's a
> reasonable compromise. Are you just worried about the memory and cpu
> cycles or is it actually a lot of code?
Well, the problem is that it uglifies the code quite a lot. The patch
as I've got it now adds a "flags" field to ObjectAddress, which is
unused dead space for about half of the uses of ObjectAddress; to keep
the old behavior we'd need to either add three more half-used fields,
or persuade ObjectAddresses to manage two parallel arrays, neither of
which seems very nice. I'll do it if people want it, but I thought
first I should ask if anyone really cares.
> Incidentally, if it happens to be straightforward (I suspect not :( ) in the
> above example it would be nice to compress out the internal dependencies and
> show just the "view b depends on function a(text)" which would actually make
> sense to a DBA. The intermediate rules going via internal objects (rules)
> they've never heard of make it a lot harder to read.
Actually, I think the patch as I've got it now will behave that way
(though it's not done enough to test yet ...)
>> BTW, it would now be possible to do something like what the shdepend
>> code does, and stuff all these reports into the DETAIL field of a
>> single message, instead of emitting them as separate notices.
>> Any feelings pro or con about that?
> Seems fine either way -- I wonder if one way is more convenient for pgadmin or
> applications? I suspect if so it would be the DETAIL field?
The arguments are all about the same as they were for shdepend messages,
I think. The case to think about is where there are LOTS of
dependencies. Do you want 10000 separate NOTICE messages, or a large,
perhaps truncated DETAIL field? I don't recall for sure, but I think
we made the shdepend code act the way it does because we thought that
was better --- certainly it would've been easy to make it just spit
individual NOTICES like the older pg_depend code does.
regards, tom lane