2011/6/16 Luiz K. Matsumura :
> Em 16/06/2011 16:39, Robert Haas escreveu:
>
> 2011/6/10 Luiz K. Matsumura :
>
> I need help to know if the follow scenario is a expected behaviour, a bug of
> postgres or a bug of slony:
>
> Postgres v8.4.8
> Slony-I v 2.0.5
>
> I have table replicated with slony an
Em 16/06/2011 16:39, Robert Haas escreveu:
2011/6/10 Luiz K. Matsumura:
I need help to know if the follow scenario is a expected behaviour, a bug of
postgres or a bug of slony:
Postgres v8.4.8
Slony-I v 2.0.5
I have table replicated with slony and that do some updates in another table
not re
Em 16/06/2011 19:17, Christopher Browne escreveu:
2011/6/10 Luiz K. Matsumura:
Hi,
I need help to know if the follow scenario is a expected behaviour, a bug of
postgres or a bug of slony:
Postgres v8.4.8
Slony-I v 2.0.5
I have table replicated with slony and that do some updates in another t
2011/6/10 Luiz K. Matsumura :
> I need help to know if the follow scenario is a expected behaviour, a bug of
> postgres or a bug of slony:
>
> Postgres v8.4.8
> Slony-I v 2.0.5
>
> I have table replicated with slony and that do some updates in another table
> not replicated.
>
> The trigger on repl
Chris Studholme <[EMAIL PROTECTED]> writes:
> What follows is not necessarily a bug, but may be a misinterpretation of
> the SQL standard.
Yeah, it's a bug; the implementation of row comparisons in PG is
completely bogus. (The parser just expands it out to an AND clause
of scalar comparisons, whi
On 18 Jul 2002, [ISO-8859-1] Stéphane Raimbault wrote:
> Hi,
>
> I have the following tables :
> CREATE TABLE tournee (
>no_tournee SERIAL PRIMARY KEY);
>
> CREATE TABLE fab_tournee (
>id SERIAL PRIMARY KEY,
>id_fab INTEGER REFERENCES fabrication ON DELETE CASCADE,
>
