Re: BUG #7758: pg_dump does not correctly dump operators.

I found an example that breaks on Postgres 9.1.7! Just define TWO operators=
! Try this:

-------------- Start of SQL script -----------
begin;

CREATE OR REPLACE FUNCTION text_natsort_gt(text, text) RETURNS boolean AS
'SELECT bttext_pattern_cmp($1,$2) > 0'
LANGUAGE 'sql' IMMUTABLE STRICT COST 1;

CREATE OR REPLACE FUNCTION text_natsort_lt(text, text) RETURNS boolean AS
'SELECT bttext_pattern_cmp($1,$2) < 0'
LANGUAGE 'sql' IMMUTABLE STRICT COST 1;

DROP OPERATOR IF EXISTS #<#(text,text) CASCADE;
CREATE OPERATOR #<#(
  PROCEDURE =3D text_natsort_lt,
  LEFTARG =3D text,
  RIGHTARG =3D text,
  COMMUTATOR =3D #>#,
  RESTRICT =3D scalarltsel,
  JOIN =3D scalarltjoinsel);

DROP OPERATOR IF EXISTS #<=3D#(text,text) CASCADE;
CREATE OPERATOR #<=3D#(
  PROCEDURE =3D text_natsort_lt,
  LEFTARG =3D text,
  RIGHTARG =3D text,
  COMMUTATOR =3D #>=3D#,
  RESTRICT =3D scalarltsel,
  JOIN =3D scalarltjoinsel);
 =20
DROP OPERATOR IF EXISTS #>#(text,text) CASCADE;
CREATE OPERATOR #>#(
  PROCEDURE =3D text_natsort_gt,
  LEFTARG =3D text,
  RIGHTARG =3D text,
  COMMUTATOR =3D #<#,
  RESTRICT =3D scalargtsel,
  JOIN =3D scalargtjoinsel);

DROP OPERATOR IF EXISTS #>=3D#(text,text) CASCADE;
CREATE OPERATOR #>=3D#(
  PROCEDURE =3D text_natsort_gt,
  LEFTARG =3D text,
  RIGHTARG =3D text,
  COMMUTATOR =3D #<=3D#,
  RESTRICT =3D scalargtsel,
  JOIN =3D scalargtjoinsel);

commit;

-------------- End of SQL script -----------

Then do a plain dump and see pg_dump fail!

PS: The second mail just has the mailing list in CC, sorry for forgetting t=
his before.


-----Urspr=FCngliche Nachricht-----
Von: Tom Lane [mailto:tgl@sss.pgh.pa.us]=20
Gesendet: Mittwoch, 19. Dezember 2012 20:09
An: Daniel Migowski
Cc: pgsql-bugs@postgresql.org
Betreff: Re: [BUGS] BUG #7758: pg_dump does not correctly dump operators.

dmigowski@ikoffice.de writes:
> When inserted into an empty DB on an 9.1.2 system, then pg_dump will=20
> generate wrong CUMMUTATOR clauses, but only for the first operator:
> ...
> Sadly, when I use these operators in my real world database running on=20
> 9.1.7, the problem is still there:

Indeed, I do not see a problem with this example on 9.1.7.  Can you extract=
 a self-contained example that does fail with 9.1.7?

            regards, tom lane