NetBSD/MIPS supports dlopen

R�mi Zara wrote:

Hi,

Recent version of NetBSD/MIPS support dlopen. This patch makes the
netbsd dynloader tests availability of dlopen on HAVE_DLOPEN rather than
on __mips__

Applied, thanks.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre@commandprompt.com> writes:

R�mi Zara wrote:

Recent version of NetBSD/MIPS support dlopen. This patch makes the
netbsd dynloader tests availability of dlopen on HAVE_DLOPEN rather than
on __mips__

Applied, thanks.

Weird, I haven't seen the commit message come through here.

Anyway: (1) this should probably be back-patched; (2) please clean up
the ugly double negative here:

! #if !defined(HAVE_DLOPEN)
#else
dlclose(handle);
#endif

regards, tom lane

I've attached a patch, against current 8.4 cvs, which optionally sets a
maximum width for psql output:

# \pset format aligned-wrapped
# \pset border 2
# select * from distributors order by did;
+------+--------------------+---------------------+---------------+
| did  |        name        |        descr        | long_col_name |
+------+--------------------+---------------------+---------------+
|    1 | Food fish and wine | default             |               |
|    2 | Cat Food Heaven 2  | abcdefghijklmnopqrs !               |
|      |                    | tuvwxyz             |               |
|    3 | Cat Food Heaven 3  | default             |               |
|   10 | Lah                | default             |               |
|   12 | name               | line one            |               |
| 2892 ! short name         | short               |               |
| 8732 |                    |                     |               |
+------+--------------------+---------------------+---------------+
(8 rows)

The interactive terminal column width comes from
char * temp = getenv("COLUMNS");
Which has the strong advantage of great simplicity and portability. But
it may not be 1000% universal. If $COLUMNS is not defined, the code
bails to assuming an infinitely wide terminal.

I will also backport this to Postgres 8.1, for my own use. Though the
code is almost totally different in structure.

Bryce Nesbitt
City CarShare San Francisco

Tom Lane wrote:

Alvaro Herrera <alvherre@commandprompt.com> writes:

R�mi Zara wrote:

Recent version of NetBSD/MIPS support dlopen. This patch makes the
netbsd dynloader tests availability of dlopen on HAVE_DLOPEN rather than
on __mips__

Applied, thanks.

Anyway: (1) this should probably be back-patched; (2) please clean up
the ugly double negative here:

Both done -- I backpatched all the way down to 7.4 (and later I noticed
that the only 7.3 BF members are NetBSD).

Weird, I haven't seen the commit message come through here.

Yeah, that's strange -- the (2) commit message got to me, but this one
hasn't.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera <alvherre@commandprompt.com> writes:

Tom Lane wrote:

Weird, I haven't seen the commit message come through here.

Yeah, that's strange -- the (2) commit message got to me, but this one
hasn't.

Moderation filter got it for some reason? None of the back-patch
commits came through either, so there's something going on there...

regards, tom lane

Alvaro Herrera wrote:

Both done -- I backpatched all the way down to 7.4 (and later I noticed
that the only 7.3 BF members are NetBSD).

Haven't we declared 7.3 at EOL anyway?

cheers

andrew

Tom Lane wrote:

Alvaro Herrera <alvherre@commandprompt.com> writes:

Tom Lane wrote:

Weird, I haven't seen the commit message come through here.

Yeah, that's strange -- the (2) commit message got to me, but this one
hasn't.

Moderation filter got it for some reason?

Hmm, not moderation, because I am a moderator and didn't get it.

None of the back-patch
commits came through either, so there's something going on there...

Perhaps it's the fact that I used R�mi's name with the accent. I'll
check Majordomo logs if it lets me.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Andrew Dunstan wrote:

Alvaro Herrera wrote:

Both done -- I backpatched all the way down to 7.4 (and later I noticed
that the only 7.3 BF members are NetBSD).

Haven't we declared 7.3 at EOL anyway?

That's why I didn't backpatch it there. But if that's the case, why are
we still reporting 7.3 in the buildfarm status page?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:

Tom Lane wrote:

Alvaro Herrera <alvherre@commandprompt.com> writes:

Tom Lane wrote:

Weird, I haven't seen the commit message come through here.

Yeah, that's strange -- the (2) commit message got to me, but this one
hasn't.

None of the back-patch
commits came through either, so there's something going on there...

Perhaps it's the fact that I used R�mi's name with the accent. I'll
check Majordomo logs if it lets me.

I checked the Majordomo logs and there's nothing about those patches.
I do see one message with the "Subject: pgsql: Clean up double negative,
per Tom Lane." line. A message held for moderation shows up in the logs
with a "stall" status. So these messages where chopped _before_ they
got into Majordomo at all ...

Perhaps a bug in the script that sends the email?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:

Alvaro Herrera wrote:

Tom Lane wrote:

Alvaro Herrera <alvherre@commandprompt.com> writes:

Tom Lane wrote:

Weird, I haven't seen the commit message come through here.

Yeah, that's strange -- the (2) commit message got to me, but this one
hasn't.

None of the back-patch
commits came through either, so there's something going on there...

Perhaps it's the fact that I used R�mi's name with the accent. I'll
check Majordomo logs if it lets me.

I checked the Majordomo logs and there's nothing about those patches.
I do see one message with the "Subject: pgsql: Clean up double negative,
per Tom Lane." line. A message held for moderation shows up in the logs
with a "stall" status. So these messages where chopped _before_ they
got into Majordomo at all ...

Perhaps a bug in the script that sends the email?

I see a bunch of emails from you leaving the system today. My first
guess for problem location would be the antispam, but before we rule out
the sender completely - at exactly what time was the commit(s) that made
it through made, and at what time was the commit(s) that didn't make it
through? In GMT time, please :-)

//Magnus

Alvaro Herrera wrote:

Andrew Dunstan wrote:

Alvaro Herrera wrote:

Both done -- I backpatched all the way down to 7.4 (and later I noticed
that the only 7.3 BF members are NetBSD).

Haven't we declared 7.3 at EOL anyway?

That's why I didn't backpatch it there. But if that's the case, why are
we still reporting 7.3 in the buildfarm status page?

Because until a couple of weeks ago those two machines were still
reporting that branch. When they are 30 days old the reports will drop
off the page. (It looks like salamander has stopped altogether, which
Tom mentioned the other day would distress him some.)

cheers

andrew

Magnus Hagander wrote:

Alvaro Herrera wrote:

I checked the Majordomo logs and there's nothing about those patches.
I do see one message with the "Subject: pgsql: Clean up double negative,
per Tom Lane." line. A message held for moderation shows up in the logs
with a "stall" status. So these messages where chopped _before_ they
got into Majordomo at all ...

Perhaps a bug in the script that sends the email?

I see a bunch of emails from you leaving the system today. My first
guess for problem location would be the antispam, but before we rule out
the sender completely - at exactly what time was the commit(s) that made
it through made, and at what time was the commit(s) that didn't make it
through? In GMT time, please :-)

Huh, I have zero idea and I had already closed the windows. So, from
the CVS logs:

revision 1.23
date: 2008/03/05 19:42:11; author: alvherre; state: Exp; lines: +4 -4
Add support for dlopen on recent NetBSD/MIPS, per R�mi Zara.
...
revision 1.12.4.1
date: 2008/03/05 21:20:49; author: alvherre; state: Exp; lines: +3 -4
Add support for dlopen on recent NetBSD/MIPS, per R�mi Zara.
----------------------------
revision 1.16.4.1
date: 2008/03/05 21:20:48; author: alvherre; state: Exp; lines: +3 -4
Add support for dlopen on recent NetBSD/MIPS, per R�mi Zara.
----------------------------
revision 1.17.2.1
date: 2008/03/05 21:20:49; author: alvherre; state: Exp; lines: +3 -4
Add support for dlopen on recent NetBSD/MIPS, per R�mi Zara.
----------------------------
revision 1.19.2.1
date: 2008/03/05 21:20:48; author: alvherre; state: Exp; lines: +4 -5
Add support for dlopen on recent NetBSD/MIPS, per R�mi Zara.
----------------------------
revision 1.22.2.1
date: 2008/03/05 21:20:47; author: alvherre; state: Exp; lines: +4 -5
Add support for dlopen on recent NetBSD/MIPS, per R�mi Zara.

These are all GMT AFAICT.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Wed, Mar 05, 2008 at 07:38:21PM -0300, Alvaro Herrera wrote:

Magnus Hagander wrote:

Alvaro Herrera wrote:

I checked the Majordomo logs and there's nothing about those patches.
I do see one message with the "Subject: pgsql: Clean up double negative,
per Tom Lane." line. A message held for moderation shows up in the logs
with a "stall" status. So these messages where chopped _before_ they
got into Majordomo at all ...

Perhaps a bug in the script that sends the email?

I see a bunch of emails from you leaving the system today. My first
guess for problem location would be the antispam, but before we rule out
the sender completely - at exactly what time was the commit(s) that made
it through made, and at what time was the commit(s) that didn't make it
through? In GMT time, please :-)

Huh, I have zero idea and I had already closed the windows. So, from
the CVS logs:

This is enough - I just wanted to be sure which commits we talked about.

revision 1.23
date: 2008/03/05 19:42:11; author: alvherre; state: Exp; lines: +4 -4
Add support for dlopen on recent NetBSD/MIPS, per R�mi Zara.

19:42:11 I have one email going out to pgsql-committers from alvherre.

21:14:10 I have another, that doesn't match any of these commits. Did you
make anotherone that you didn't include in this list?

...
revision 1.12.4.1
date: 2008/03/05 21:20:49; author: alvherre; state: Exp; lines: +3 -4
Add support for dlopen on recent NetBSD/MIPS, per R�mi Zara.
----------------------------
revision 1.16.4.1
date: 2008/03/05 21:20:48; author: alvherre; state: Exp; lines: +3 -4
Add support for dlopen on recent NetBSD/MIPS, per R�mi Zara.
----------------------------
revision 1.17.2.1
date: 2008/03/05 21:20:49; author: alvherre; state: Exp; lines: +3 -4
Add support for dlopen on recent NetBSD/MIPS, per R�mi Zara.
----------------------------
revision 1.19.2.1
date: 2008/03/05 21:20:48; author: alvherre; state: Exp; lines: +4 -5
Add support for dlopen on recent NetBSD/MIPS, per R�mi Zara.
----------------------------
revision 1.22.2.1
date: 2008/03/05 21:20:47; author: alvherre; state: Exp; lines: +4 -5
Add support for dlopen on recent NetBSD/MIPS, per R�mi Zara.

21:20:47 I count 1.
21:20:48 I count 2.
21:20:49 I count 2.

All these mails have been acknowledged as received by svr1.postgresql.org.-

So the script that sends them out is working properly. I'm back at blaming
the antispam for eating them before they got out to the list. Especially
since you didn't get a boucne (I assume you would've noticed if you did)

//Magnus

Magnus Hagander wrote:

On Wed, Mar 05, 2008 at 07:38:21PM -0300, Alvaro Herrera wrote:

revision 1.23
date: 2008/03/05 19:42:11; author: alvherre; state: Exp; lines: +4 -4
Add support for dlopen on recent NetBSD/MIPS, per R�mi Zara.

19:42:11 I have one email going out to pgsql-committers from alvherre.

21:14:10 I have another, that doesn't match any of these commits. Did you
make anotherone that you didn't include in this list?

Correct.

So the script that sends them out is working properly. I'm back at blaming
the antispam for eating them before they got out to the list. Especially
since you didn't get a boucne (I assume you would've noticed if you did)

Hmm, so most likely they are in Maia's hands and only Marc can rescue
them.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Bryce Nesbitt wrote:

I've attached a patch, against current 8.4 cvs, which optionally sets a
maximum width for psql output:

I have added this patch to the May commitfest queue,

http://wiki.postgresql.org/wiki/CommitFest:May

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Bryce Nesbitt wrote:

I've attached a patch, against current 8.4 cvs, which optionally sets a
maximum width for psql output:

# \pset format aligned-wrapped
# \pset border 2
# select * from distributors order by did;
+------+--------------------+---------------------+---------------+
| did  |        name        |        descr        | long_col_name |
+------+--------------------+---------------------+---------------+
|    1 | Food fish and wine | default             |               |
|    2 | Cat Food Heaven 2  | abcdefghijklmnopqrs !               |
|      |                    | tuvwxyz             |               |
|    3 | Cat Food Heaven 3  | default             |               |
|   10 | Lah                | default             |               |
|   12 | name               | line one            |               |
| 2892 ! short name         | short               |               |
| 8732 |                    |                     |               |
+------+--------------------+---------------------+---------------+
(8 rows)

The interactive terminal column width comes from
char * temp = getenv("COLUMNS");
Which has the strong advantage of great simplicity and portability. But
it may not be 1000% universal. If $COLUMNS is not defined, the code
bails to assuming an infinitely wide terminal.

I will also backport this to Postgres 8.1, for my own use. Though the
code is almost totally different in structure.

I spent time reviewing your patch --- quite impressive. I have attached
and updated version with mostly stylistic changes.

In testing I found the regression tests were failing because of a divide
by zero error (fixed), and a missing case where the column delimiter has
to be ":". In fact I now see all your line continuation cases using ":"
rather than "!". It actually looks better --- "!" was too close to "|"
to be easily recognized. (Did you update your patch to use ":". I
didn't see "!" in your patch.)

I have added an XXX comment questioning whether the loop to find the
column to wrap is inefficient because it potentially loops over the
length of the longest column and for each character loops over the
number of columns. Not sure if that is a problem.

I checked the use of COLUMNS and it seems bash updates the environment
variable when a window is resized. I added ioctl(TIOCGWINSZ) if COLUMNS
isn't set. We already had a call in print.c for detecting the
number of rows on the screen to determine if the pager should
be used. Seems COLUMNS should take precedence over ioctl(), right?
I don't think Win32 supports that ioctl(), does it?

I added some comments and clarified some variable names. I also renamed
the option to a shorter "wrapped". I added documentation too.

For testers compare:

\df

with:

\pset format wrap
\df

Impressive!

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:

I spent time reviewing your patch --- quite impressive. I have attached
and updated version with mostly stylistic changes.

In testing I found the regression tests were failing because of a divide
by zero error (fixed), and a missing case where the column delimiter has
to be ":". In fact I now see all your line continuation cases using ":"
rather than "!". It actually looks better --- "!" was too close to "|"
to be easily recognized. (Did you update your patch to use ":". I
didn't see "!" in your patch.)

Nice! I'll merge with my current version. As you note I changed to ":".

I also found that for hugely wide output it was better to give up (do
nothing), rather than mangle the output in a futile attempt to squash it
to the window width. So there is one more clause in the wrapping if.

I have tested on several unix flavors, but not on Windows or cygwin.

-Bryce

Bruce Momjian wrote:

In testing I found the regression tests were failing because of a divide
by zero error (fixed), and a missing case where the column delimiter has
to be ":". In fact I now see all your line continuation cases using ":"
rather than "!". It actually looks better --- "!" was too close to "|"
to be easily recognized. (Did you update your patch to use ":". I
didn't see "!" in your patch.)

I think we should use a different separator when there is an actual
newline in the data. Currently we have a : there, so using a : here is
probably not the best idea.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Bruce Momjian wrote:

I checked the use of COLUMNS and it seems bash updates the environment
variable when a window is resized. �I added ioctl(TIOCGWINSZ) if COLUMNS
isn't set. �We already had a call in print.c for detecting the
number of rows on the screen to determine if the pager should
be used. �Seems COLUMNS should take precedence over ioctl(), right?

Considering that the code to determine the row count is undisputed so far, the
column count detection should work the same. That is, we might not need to
look at COLUMNS at all. Unless there is a use case for overriding the column
count (instead of just turning off the wrapping).