Thread: Error in ORDER BY on check constraints in psql

Error in ORDER BY on check constraints in psql

From
Christopher Kings-Lynne
Date:
Everything is sorted by object name in \d <table> except check
constraints for some reason.  It seems it's ordering by the wrong column.

Seems like a bug to me.

Attached is the trivial patch.

Chris
Index: src/bin/psql/describe.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/bin/psql/describe.c,v
retrieving revision 1.127
diff -c -r1.127 describe.c
*** src/bin/psql/describe.c    15 Oct 2005 02:49:40 -0000    1.127
--- src/bin/psql/describe.c    20 Oct 2005 04:58:58 -0000
***************
*** 1040,1046 ****
                                "pg_catalog.pg_get_constraintdef(r.oid, true), "
                                "conname\n"
                                "FROM pg_catalog.pg_constraint r\n"
!                     "WHERE r.conrelid = '%s' AND r.contype = 'c' ORDER BY 1",
                                oid);
              result2 = PSQLexec(buf.data, false);
              if (!result2)
--- 1040,1046 ----
                                "pg_catalog.pg_get_constraintdef(r.oid, true), "
                                "conname\n"
                                "FROM pg_catalog.pg_constraint r\n"
!                     "WHERE r.conrelid = '%s' AND r.contype = 'c' ORDER BY 2",
                                oid);
              result2 = PSQLexec(buf.data, false);
              if (!result2)

Re: Error in ORDER BY on check constraints in psql

From
Tom Lane
Date:
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> Everything is sorted by object name in \d <table> except check
> constraints for some reason.  It seems it's ordering by the wrong column.
> Seems like a bug to me.

That was probably done deliberately, back in the day when constraints
tended to have uselessly random names like "$1" --- sorting by the
constraint text was more helpful.  I agree that now sorting by name
seems like the better thing.

> Attached is the trivial patch.

I think there's nothing wrong with the "ORDER BY 1" part ... it's the
fact that the columns are selected in a different order than they'll
be used that seems bizarre to me.  I fixed it like this instead.

            regards, tom lane

*** src/bin/psql/describe.c.orig    Fri Oct 14 23:00:19 2005
--- src/bin/psql/describe.c    Thu Oct 20 01:09:29 2005
***************
*** 1036,1044 ****
          if (tableinfo.checks)
          {
              printfPQExpBuffer(&buf,
!                               "SELECT "
!                               "pg_catalog.pg_get_constraintdef(r.oid, true), "
!                               "conname\n"
                                "FROM pg_catalog.pg_constraint r\n"
                      "WHERE r.conrelid = '%s' AND r.contype = 'c' ORDER BY 1",
                                oid);
--- 1036,1043 ----
          if (tableinfo.checks)
          {
              printfPQExpBuffer(&buf,
!                               "SELECT r.conname, "
!                               "pg_catalog.pg_get_constraintdef(r.oid, true)\n"
                                "FROM pg_catalog.pg_constraint r\n"
                      "WHERE r.conrelid = '%s' AND r.contype = 'c' ORDER BY 1",
                                oid);
***************
*** 1192,1199 ****
              for (i = 0; i < check_count; i++)
              {
                  printfPQExpBuffer(&buf, _("    \"%s\" %s"),
!                                   PQgetvalue(result2, i, 1),
!                                   PQgetvalue(result2, i, 0));

                  footers[count_footers++] = pg_strdup(buf.data);
              }
--- 1191,1198 ----
              for (i = 0; i < check_count; i++)
              {
                  printfPQExpBuffer(&buf, _("    \"%s\" %s"),
!                                   PQgetvalue(result2, i, 0),
!                                   PQgetvalue(result2, i, 1));

                  footers[count_footers++] = pg_strdup(buf.data);
              }

Re: Error in ORDER BY on check constraints in psql

From
Christopher Kings-Lynne
Date:
> That was probably done deliberately, back in the day when constraints
> tended to have uselessly random names like "$1" --- sorting by the
> constraint text was more helpful.  I agree that now sorting by name
> seems like the better thing.

Even in the "$x" case, it's better to have them sorted in that order
(ie. the order they were created...)

> I think there's nothing wrong with the "ORDER BY 1" part ... it's the
> fact that the columns are selected in a different order than they'll
> be used that seems bizarre to me.  I fixed it like this instead.

Ah, the way that requires effort :)


AIX FAQ update for 5.3 socket address size issue

From
Chris Browne
Date:
IBM has addressed the socket address storage issue as of AIX 5.3
maintenance level 5300-03; the following patch adds documentation to
FAQ_AIX...

cbbrowne@dba2:OXRS/sources/pgsql-HEAD/doc> cvs diff -u FAQ_AIX
           Thursday 12:22:52 
Index: FAQ_AIX
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/FAQ_AIX,v
retrieving revision 1.12
diff -c -u -r1.12 FAQ_AIX
cvs diff: conflicting specifications of output style
--- FAQ_AIX    30 Jul 2005 03:39:27 -0000    1.12
+++ FAQ_AIX    20 Oct 2005 16:23:01 -0000
@@ -83,6 +83,24 @@
 IBM will be providing a fix in the next maintenance release (expected
 in October 2005) with an updated socket.h.
 ---
+PMR29657 was resolved in APAR IY74147: INCOMPATIBILITY BETWEEN
+SOCKADDR_UN AND SOCKADDR_STORAGE STRUCT
+
+APAR information
+APAR number    IY74147
+Reported component name    AIX 5.3
+Reported component ID    5765G0300
+Reported release    530
+Status    CLOSED PER
+PE    NoPE
+HIPER    NoHIPER
+Submitted date    2005-07-18
+Closed date    2005-07-18
+Last modified date    2005-09-06
+
+If you upgrade to maintenance level 5300-03, that will include this
+fix. Use the command "oslevel -r" to determine what maintenance level
+you are at.
+---
 From: Christopher Browne <cbbrowne@ca.afilias.info>
 Date: 2005-07-15
--
output = reverse("moc.enworbbc" "@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/oses.html
Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf. --- James Simmons

Re: AIX FAQ update for 5.3 socket address size issue

From
Bruce Momjian
Date:
Patch applied.  Thanks.

---------------------------------------------------------------------------


Chris Browne wrote:
> IBM has addressed the socket address storage issue as of AIX 5.3
> maintenance level 5300-03; the following patch adds documentation to
> FAQ_AIX...
>
> cbbrowne@dba2:OXRS/sources/pgsql-HEAD/doc> cvs diff -u FAQ_AIX
             Thursday 12:22:52 
> Index: FAQ_AIX
> ===================================================================
> RCS file: /projects/cvsroot/pgsql/doc/FAQ_AIX,v
> retrieving revision 1.12
> diff -c -u -r1.12 FAQ_AIX
> cvs diff: conflicting specifications of output style
> --- FAQ_AIX    30 Jul 2005 03:39:27 -0000    1.12
> +++ FAQ_AIX    20 Oct 2005 16:23:01 -0000
> @@ -83,6 +83,24 @@
>  IBM will be providing a fix in the next maintenance release (expected
>  in October 2005) with an updated socket.h.
>  ---
> +PMR29657 was resolved in APAR IY74147: INCOMPATIBILITY BETWEEN
> +SOCKADDR_UN AND SOCKADDR_STORAGE STRUCT
> +
> +APAR information
> +APAR number    IY74147
> +Reported component name    AIX 5.3
> +Reported component ID    5765G0300
> +Reported release    530
> +Status    CLOSED PER
> +PE    NoPE
> +HIPER    NoHIPER
> +Submitted date    2005-07-18
> +Closed date    2005-07-18
> +Last modified date    2005-09-06
> +
> +If you upgrade to maintenance level 5300-03, that will include this
> +fix. Use the command "oslevel -r" to determine what maintenance level
> +you are at.
> +---
>  From: Christopher Browne <cbbrowne@ca.afilias.info>
>  Date: 2005-07-15
> --
> output = reverse("moc.enworbbc" "@" "enworbbc")
> http://www3.sympatico.ca/cbbrowne/oses.html
> Q: Why did they deprecate a.out support in linux?
> A: Because a nasty coff is bad for your elf. --- James Simmons
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073