>
>I'll make the change ASAP.
>
Now in CVS along with PG 7.0 compat. code.
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498) | /(@) ___
At 11:29 20/04/01 -0500, Jan Wieck wrote:
>Philip Warner wrote:
>> At 08:42 19/04/01 -0500, Jan Wieck wrote:
>> >and the required
>> >feature to correctly restore the tgconstrrelid is already in
>> >the backend, so pg_dump should make use of it
>>
>> No problem there - just tell
Philip Warner wrote:
> At 08:42 19/04/01 -0500, Jan Wieck wrote:
> [...]
> >and the required
> >feature to correctly restore the tgconstrrelid is already in
> >the backend, so pg_dump should make use of it
>
> No problem there - just tell me how...
Add a "FROM " after the
On Thu, 19 Apr 2001, Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > IMHO there's nothing fundamentally wrong with having pg_dump
> > dumping the constraints as special triggers, because they are
> > implemented in PostgreSQL as triggers. ...
> > The advantage of
On Thu, 19 Apr 2001, Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > IMHO there's nothing fundamentally wrong with having pg_dump
> > dumping the constraints as special triggers, because they are
> > implemented in PostgreSQL as triggers. ...
> > The advantage of
Jan Wieck <[EMAIL PROTECTED]> writes:
> IMHO there's nothing fundamentally wrong with having pg_dump
> dumping the constraints as special triggers, because they are
> implemented in PostgreSQL as triggers. ...
> The advantage of having pg_dump output these constraints as
>
At 08:42 19/04/01 -0500, Jan Wieck wrote:
>>
>> It's because pg_dump is not designed to dump these constraints *as*
>> constraints. We just need to make pg_dump clever enough to do that.
>
>IMHO there's nothing fundamentally wrong with having pg_dump
>dumping the constraints as special tr
Philip Warner wrote:
> At 16:25 18/04/01 -0400, Joel Burton wrote:
> >
> >Do we know if the problem is in pg_dump, or is there no way
> >to pass the tgconstrrelid value in the CREATE CONSTRAINT TRIGGER
> >statement?
> >
>
> It's because pg_dump is not designed to dump these constraints *as*
> cons
At 16:25 18/04/01 -0400, Joel Burton wrote:
>
>Do we know if the problem is in pg_dump, or is there no way
>to pass the tgconstrrelid value in the CREATE CONSTRAINT TRIGGER
>statement?
>
It's because pg_dump is not designed to dump these constraints *as*
constraints. We just need to make pg_dump
At 16:30 18/04/01 -0400, Tom Lane wrote:
>
>IIRC, pg_dump is just failing to transfer the value; it needs to emit
>an additional clause in the CREATE CONSTRAINT command to do so.
>
>From memory, this is one of the non-standard SQL things that pg_dump still
does (ie. definining the constraint usin
On Wed, 18 Apr 2001, Tom Lane wrote:
> Joel Burton <[EMAIL PROTECTED]> writes:
> > tgconstrrelid (in pg_trigger) holds table references in a RI trigger.
> > The value in this field is not successfully recreated after a
> > dump/restore.
>
> Yes, this problem was noted a couple months ago. AFAIK
Joel Burton <[EMAIL PROTECTED]> writes:
> Do we know if the problem is in pg_dump, or is there no way
> to pass the tgconstrrelid value in the CREATE CONSTRAINT TRIGGER
> statement?
IIRC, pg_dump is just failing to transfer the value; it needs to emit
an additional clause in the CREATE CONSTRAINT
12 matches
Mail list logo
