At 11:07 PM 1/08/2003 -0400, Tom Lane wrote:
So all the dependency info must appear at the front.
Correct. It currently gets stored in the TOC, which is at the front, and is
read into memory at the start of the restore process.
Phil
Philip Warner <[EMAIL PROTECTED]> writes:
> In terms of the dependency data, I was planning to dump dependencies as
> well (a trivial skeleton exists); the ordering should happen at
> restore-time (except dump should store it in useful-order on the assumption
> that it will not be possible to r
At 11:44 AM 1/08/2003 +0800, Christopher Kings-Lynne wrote:
> What I'd like to see it do is grab the dependency data in pg_depend and
> do a topological sort using that.
At the end though, we'd need to dump stuff not caught be the topsort, for
cases where pg_depend has been messed with.
I have made
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> This leaves some issues still to be
>> resolved ... like what to do when dumping a pre-7.3 database ... but I
>> think it's the core of a maintainable solution.
> Problem is you'd need to sort tables by the youngest column in the table,
> wh
> What I'd like to see it do is grab the dependency data in pg_depend and
> do a topological sort using that.
At the end though, we'd need to dump stuff not caught be the topsort, for
cases where pg_depend has been messed with.
> This leaves some issues still to be
> resolved ... like what to do
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Can someone tell me know what has to be done to pg_dump to make it dump
> things in the right order? Where should I start. The most important thing
> is getting types dumped before tables that use the type.
What I'd like to see it do is gra
Christopher Kings-Lynne writes:
> I remember a while back you were saying you were working on pg_dump object
> ordering? What happened with that? Did you need some help with it?
I don't remember that and I don't have any specific plans relating to
that.
--
Peter Eisentraut [EMAIL PROTECTED]
Philip Warner <[EMAIL PROTECTED]> writes:
> I don't suppose we can change the pg_views view without an initdb?
No, not very readily.
Even assuming that we were willing to require dbadmins to run a script
during upgrade (which I wouldn't want to do unless forced to it), it's
not that easy to fix
At 17:34 13/04/01 -0400, Tom Lane wrote:
>
>A possible kluge answer is to make pg_dump's OID-ordering of views
>depend on the OID of the view rule rather than the view relation.
>I am not sure if that would break any cases that work now, however.
>
Fixed in CVS.
-
At 18:29 14/04/01 +1000, Philip Warner wrote:
>
>I don't suppose we can change the pg_views view without an initdb?
>
Having now looked at the source, I realize that initdb is where this view
is defined. However, is there any reason that we can not change this
definition when upgrading to 7.1.1?
At 03:53 14/04/01 -0400, Tom Lane wrote:
>
>> Would people mind me adding a 'pg_getviewoid()' for pg_dump's use?
>
>While that would be a clean solution, it would mean that the problem
>will remain until 7.2, because you don't get to assume another initdb
>until 7.2. I don't think we want to wait
Philip Warner <[EMAIL PROTECTED]> writes:
> Having now looked at pg_dump more closely, I'm not at all sure I want to
> make the change directly in pg_dump. The reason is that I am trying to move
> version-specific stuff from pg_dump, and I currently get a view definition
> by doing 'select pg_getv
>>> >
>>> >A possible kluge answer is to make pg_dump's OID-ordering of views
>>> >depend on the OID of the view rule rather than the view relation.
>>> >I am not sure if that would break any cases that work now, however.
>>> >
>>>
>>> This seems good to me; it should be based on the 'oid of the
At 21:15 13/04/01 -0400, Bruce Momjian wrote:
>> At 17:34 13/04/01 -0400, Tom Lane wrote:
>> >
>> >A possible kluge answer is to make pg_dump's OID-ordering of views
>> >depend on the OID of the view rule rather than the view relation.
>> >I am not sure if that would break any cases that work now,
> At 17:34 13/04/01 -0400, Tom Lane wrote:
> >
> >A possible kluge answer is to make pg_dump's OID-ordering of views
> >depend on the OID of the view rule rather than the view relation.
> >I am not sure if that would break any cases that work now, however.
> >
>
> This seems good to me; it should
At 17:34 13/04/01 -0400, Tom Lane wrote:
>
>A possible kluge answer is to make pg_dump's OID-ordering of views
>depend on the OID of the view rule rather than the view relation.
>I am not sure if that would break any cases that work now, however.
>
This seems good to me; it should be based on the
I see the problem. Your 7.0.3 dump contains several instances of this
pattern:
CREATE TABLE "users_alertable" (
"user_id" int4,
"email" character varying(100),
"first_names" character varying(100),
"last_name" character varying(100),
"password" character v
Tom,
> > dump), anyone interested may have them for testing.
>
> Please. Philip Warner would likely want to see them too.
I don't have his email address... but I am quite willing to send it.
Pascal.
---(end of broadcast)---
TIP 4: Don't 'kill
Pascal Scheffers <[EMAIL PROTECTED]> writes:
> Some five functions are used in views before their definitions. In the
> original (7.0) dump they were in the correct order, but rc2/4 (the only
> ones I tried) got it wrong. The original OIDs for the
> functions in the 7.1 dump are lower than those o
At 18:53 11/04/01 +0200, Pascal Scheffers wrote:
> I have a copy
>of the relevant dumps (both the initial 7.0.3 >> 7.1rc2 and the rc4 >> rc4
>dump), anyone interested may have them for testing.
Yes please.
Philip Warner
20 matches
Mail list logo
