On Fri, Jan 14, 2011 at 09:39, Joel Jacobson wrote:
> 2011/1/12 Alvaro Herrera :
>> I think this code should live in the Wiki somewhere:
>> http://wiki.postgresql.org/wiki/Snippets
>
> This file contains only the relevant remapping of pg_depend, folding
> the internal linkages properly:
>
> https:
2011/1/12 Alvaro Herrera :
> I think this code should live in the Wiki somewhere:
> http://wiki.postgresql.org/wiki/Snippets
This file contains only the relevant remapping of pg_depend, folding
the internal linkages properly:
https://github.com/gluefinance/pov/blob/master/sql/schema/pov/views/pg_
2011/1/13 David Fetter :
> Please put a self-contained example on the snippets page, and please
> also to check that it actually runs before doing so. You'd mangled
> some aliases in the query you sent, which leads me to believe you
> hadn't actually tried running it.
I actually hadn't really sol
On Wed, Jan 12, 2011 at 09:09:31PM +0100, Joel Jacobson wrote:
> (sorry for top posting,
No worries.
> iPhone + drunk)
A dangerous combination indeed. I hear water, NSAIDs and time can
help with the hangover ;)
> pg_depend_before is a select * from pg_depend before creating the
> test db model
(sorry for top posting, iPhone + drunk)
pg_depend_before is a select * from pg_depend before creating the test db model
Sent from my iPhone
On 12 jan 2011, at 20:36, David Fetter wrote:
> On Wed, Jan 12, 2011 at 08:06:24PM +0100, Joel Jacobson wrote:
>> 2011/1/12 Tom Lane :
>>> I've sometimes
On Wed, Jan 12, 2011 at 08:06:24PM +0100, Joel Jacobson wrote:
> 2011/1/12 Tom Lane :
> > I've sometimes found it useful to think of internal dependencies as
> > acting like normal dependencies pointing in the other direction.
> > I'm not sure that would do much to solve your problem, but it might
Excerpts from Joel Jacobson's message of mié ene 12 16:06:24 -0300 2011:
> The query below can both produce a DOT-format graph and a tsort of the
> creatable order of objects:
>
> WITH
> NewObjectOids AS (
> SELECT * FROM pg_depend WHERE deptype <> 'p'
> EXCEPT
> SELECT * FROM pg_depe
On Wed, Jan 12, 2011 at 2:06 PM, Joel Jacobson wrote:
> Tom, you are a genious! No, seriously, I mean it, this is awesome, it
> worked! YES! You totally saved my day! Thank you! Finally! I'm so
> happy! :-) :-) :-)
Hey, guys, I think it worked...!
--
Robert Haas
EnterpriseDB: http://www.enter
Joel Jacobson writes:
> 2011/1/12 Tom Lane :
>> This isn't particularly *useful*, maybe, but it's hardly "impossible".
>> And if we analyzed function dependencies in any detail, circular
>> dependencies among functions would be possible (and useful).
> Thanks Tom for clarifying, this makes me eve
2011/1/12 Tom Lane :
> This isn't particularly *useful*, maybe, but it's hardly "impossible".
> And if we analyzed function dependencies in any detail, circular
> dependencies among functions would be possible (and useful).
Thanks Tom for clarifying, this makes me even more motivated into
implemen
Joel Jacobson writes:
> Also, circular dependencies seems impossible for some object classes,
> such as functions, views, constraints and triggers.
regression=# create table tt(f1 int, f2 int);
CREATE TABLE
regression=# create view v1 as select * from tt;
CREATE VIEW
regression=# create view v2 a
2011/1/12 Alvaro Herrera :
> FWIW this idea fails when you consider stuff such as circular foreign
> keys (and I suppose there are other, more common cases). If you really
> want something general you need to break those apart. (This is the
> explanation for the “break the loop” code in pg_dump I
Excerpts from Joel Jacobson's message of mié ene 12 07:07:35 -0300 2011:
> The automatically created objects, such as primary key indexes,
> constraints and triggers, have been ignored in this graph, as they are
> implicitly created when creating the "base objects".
FWIW this idea fails when you
2011/1/12 Florian Pflug :
> I suggest you try to node-folding strategy and see how far it gets you.
Good suggestion! :-) That's exactly what I've been trying to do, but
failed miserably :-(
I have written a thorough description of my problem and put it on my github:
https://github.com/gluefinanc
On Jan11, 2011, at 23:55 , Joel Jacobson wrote:
> 2011/1/11 Florian Pflug :
>> Could you give an example of the kind of trouble you're experiencing trying
>> to use a topological sort?
>
> Let's say you have a table t and a view v.
> The view v is defined as select * from t;
> If we put all object
2011/1/11 Florian Pflug :
> Could you give an example of the kind of trouble you're experiencing trying
> to use a topological sort?
Let's say you have a table t and a view v.
The view v is defined as select * from t;
If we put all objects in a tree, with the public schema as the root,
both v and
On Jan11, 2011, at 16:54 , Joel Jacobson wrote:
> Has anyone written a in-depth description on how to traverse the pg_depend
> tree?
> The 'a' and 'i' deptype really makes it hard to figure out the
> dependency order, a topological sort does not work.
Could you give an example of the kind of trou
Joel Jacobson writes:
> I need to figure out the order of creation of all objects, not just
> the dependencies for a single object.
In that case try pg_dump's pg_dump_sort.c. You will never get "the"
order of creation of objects, because that isn't tracked; but you can
find out what a safe order
2011/1/11 Tom Lane :
> Try reading the code in src/backend/catalog/dependency.c.
I've tried but failed to figure it out anyway. The focus in
dependency.c is to find out dependencies of a given object.
What I want to do is something slighly different.
I need to figure out the order of creation of a
Joel Jacobson writes:
> Has anyone written a in-depth description on how to traverse the pg_depend
> tree?
Try reading the code in src/backend/catalog/dependency.c.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Has anyone written a in-depth description on how to traverse the pg_depend tree?
The 'a' and 'i' deptype really makes it hard to figure out the
dependency order, a topological sort does not work.
My latest attempt involved trying to group by all objects connected to
each other via deptype 'a' or '
21 matches
Mail list logo
