Lists: | pgsql-patchespgsql-ports |
---|
From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Error in ORDER BY on check constraints in psql |
Date: | 2005-10-20 05:05:37 |
Message-ID: | 435725A1.5070900@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-patches pgsql-ports |
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
Attachment | Content-Type | Size |
---|---|---|
describe.txt | text/plain | 928 bytes |
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Error in ORDER BY on check constraints in psql |
Date: | 2005-10-20 05:19:15 |
Message-ID: | 5462.1129785555@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-patches pgsql-ports |
Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)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);
}
From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Error in ORDER BY on check constraints in psql |
Date: | 2005-10-20 05:28:54 |
Message-ID: | 43572B16.3020806@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-patches pgsql-ports |
> 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 :)
From: | Chris Browne <cbbrowne(at)acm(dot)org> |
---|---|
To: | pgsql-patches(at)postgresql(dot)org, pgsql-ports(at)postgresql(dot)org |
Subject: | AIX FAQ update for 5.3 socket address size issue |
Date: | 2005-10-20 16:27:41 |
Message-ID: | 60psq0dugy.fsf@dba2.int.libertyrms.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-patches pgsql-ports |
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(at)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(at)ca(dot)afilias(dot)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
From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Chris Browne <cbbrowne(at)acm(dot)org> |
Cc: | pgsql-patches(at)postgresql(dot)org, pgsql-ports(at)postgresql(dot)org |
Subject: | Re: AIX FAQ update for 5.3 socket address size issue |
Date: | 2005-10-24 22:30:41 |
Message-ID: | 200510242230.j9OMUft26011@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-patches pgsql-ports |
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(at)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(at)ca(dot)afilias(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073