On Sat, 2002-11-16 at 15:49, Alvaro Herrera wrote:
> On Fri, Nov 15, 2002 at 11:43:47AM -0500, Rod Taylor wrote:
>
> > Below is a summary of what pg_depend tracks that might be useful.
> > Skipped a number of dependencies that are internal only (ie. toast table
> > dependencies) as they will be r
At 11:43 AM 15/11/2002 -0500, Rod Taylor wrote:
Below is a summary of what pg_depend tracks that might be useful.
This looks excellent. If people are happy with my earlier outline, it
should be reasonably easy to proceed...
Phi
On Wed, 2002-11-13 at 23:37, Philip Warner wrote:
> At 02:53 PM 13/11/2002 -0500, Rod Taylor wrote:
> >I can make a complete list tonight of whats captured.
>
> Sounds good
Below is a summary of what pg_depend tracks that might be useful.
Skipped a number of dependencies that are internal only (
Philip Warner <[EMAIL PROTECTED]> writes:
> At 12:39 AM 14/11/2002 -0500, Neil Conway wrote:
>> Perhaps when the function is defined, we run all the SQL queries in
>> the function body through the parser/analyzer/rewriter, and then
>> generate dependencies on the Query trees we get back?
> Won't w
Philip Warner <[EMAIL PROTECTED]> writes:
> Won't work for functions that build dynamic queries.
Granted, but the the intent is to
(a) solve some, but not necessarily all, of the dump-order
problems
(b) drop functions that depend on a database object when the
At 12:39 AM 14/11/2002 -0500, Neil Conway wrote:
Perhaps when the function is defined, we run all the SQL queries in
the function body through the parser/analyzer/rewriter, and then
generate dependencies on the Query trees we get back?
Won't work for functions that build dynamic queries. But it
Tom Lane <[EMAIL PROTECTED]> writes:
> * We don't store dependencies for SQL functions to things mentioned in
> the SQL function body. (Maybe we should, but we don't.) So there's
> data missing in that case, and possibly other cases.
This might be interesting to do, and we could tie it into the
At 02:53 PM 13/11/2002 -0500, Rod Taylor wrote:
I can make a complete list tonight of whats captured.
Sounds good.
If you can also indicate which parts of functions are captured - arguments,
return type and body? IIRC, only SQL functions are compiled at define-time,
so other functions *should
> The thought that I'd been toying with is to build a list of inter-object
> dependencies (using pg_depend if available, else fall back on pg_dump's
> native wit, ie, the rather limited set of dependencies it already
> understands). Then do a topological sort, preferring to maintain OID
> order in
> Do we have a list of dependency data that we collect? eg. do we know about
> functions used in views and indexes? At this stage it's probably worth
> - constraints
> - sequences set (not really a dependency problem)
> - indexes
> - comments
I can make a complete list tonight of whats captured
At 09:29 AM 13/11/2002 -0500, Rod Taylor wrote:
An ALAP scheduling algorithm will almost always sort these things to be
side by side to allow combining on a second pass by something with the
intelligence.
Do we have a list of dependency data that we collect? eg. do we know about
functions used
Philip Warner <[EMAIL PROTECTED]> writes:
> The suggestion of breaking items into create/alter etc is interesting - I
> assume you are thinking of function bodies? Or is there something else?
Let's see --- foreign-key constraints are an obvious source of possible
circularities, but I see pg_dump
On Wed, 2002-11-13 at 09:08, Philip Warner wrote:
> At 08:52 AM 13/11/2002 -0500, Rod Taylor wrote:
> >The biggest trick will be trying to re-combine the ALTER ... ADD
> >CONSTRAINT and ALTER ... SET DEFAULT statements back into CREATE TABLE
>
> I'm not sure this would be worth the effort - I'll g
At 08:52 AM 13/11/2002 -0500, Rod Taylor wrote:
The biggest trick will be trying to re-combine the ALTER ... ADD
CONSTRAINT and ALTER ... SET DEFAULT statements back into CREATE TABLE
I'm not sure this would be worth the effort - I'll grant it would be cute,
but getting pg_dump to understand S
At 01:50 PM 13/11/2002 +0800, Christopher Kings-Lynne wrote:
Well, the problem is that you can add a new type and then add a column to a
really old table that uses that type - that causes pain\
You may have misunderstood; I meant to add each type used by the table to
the deps list for a table (
> pg_dump already has rudimentary dependency tracking (one level
> deep); each
> item can have a list of oid's it depends on. You *could* patch it to add
> the types to the table dependencies.
>
> In the future I'd imagine we'll just dump the OIDs of all first level
> dependencies for each object,
At 01:33 PM 13/11/2002 +0800, Christopher Kings-Lynne wrote:
Does this sound like an idea?
It does, but in keeping with allowing pg_restore to be quite flexible, I'd
like to see the dependency data stored in the dump file, then processed at
restore-time.
I've just become rather frustrated tr
Hi,
Has anyone given much thought to improving pg_dump's object order algorithm
for 7.4? It seems that now we have dependencies, it should just be a matter
of doing a breadth-first or depth-first search over the pg_depend table to
generate a valid order of oids.
To allow for mess-ups in that tab
18 matches
Mail list logo
