delta/postgresql.git, branch Release_2_0 git.postgresql.org: git/postgresql.git | 1996-08-14T16:44:51+00:00 Marc G. Fournier scrappy@hub.org 1996-08-14T16:44:51+00:00 bde34552a279a13a7980049455d6a79951cc5c5d |Here is a fix for the psql alignment problem. It turns out that libpq |was trying to determine if the column contained only numeric values so |it could right justify it. The 'e' values were taked as exponient |values and all columns were considered numeric. | |The patch excludes 'e' and 'E' as being valid first-column numeric |values. | Submitted by: Bruce... 
|Here is a fix for the psql alignment problem.  It turns out that libpq
|was trying to determine if the column contained only numeric values so
|it could right justify it.  The 'e' values were taked as exponient
|values and all columns were considered numeric.
|
|The patch excludes 'e' and 'E' as being valid first-column numeric
|values.
|

Submitted by: Bruce...
This patch can be installed as part of 1.02.1 so people can properly 1996-08-14T05:44:25+00:00 Marc G. Fournier scrappy@hub.org 1996-08-14T05:44:25+00:00 476ef109133b1e062c2805d4932ef331dda84a68 pg_dump and load to 2.0. I haven't gotten any feedback on whether people want it, so I am submitting it for others to decide. I would recommend an install in 1.02.1. I had said that the 2.0 pg_dump could dump a 1.02.1 database, but I was wrong. The copy is actually performed by the backend, and the 2.0 database will not be able to read 1.02.1 databases because of the new system columns. This patch does several things. It copies nulls out as \N, so they can be distinguished from '' strings. It fixes a problem where backslashes in the input stream were not output as double-backslashes. Without this patch, backslashes copied out were deleted upon input, or interpreted as special characters. Third, input is now terminated by backslash-period. This can not be part of a normal input stream. I tested this by creating a database with all sorts of nulls, backslash, and period fields and dumped the database and reloaded into a new database and compared them. Submitted by: Bruce 
pg_dump and load to 2.0.  I haven't gotten any feedback on whether
people want it, so I am submitting it for others to decide.  I would
recommend an install in 1.02.1.

I had said that the 2.0 pg_dump could dump a 1.02.1 database, but I was
wrong.  The copy is actually performed by the backend, and the 2.0
database will not be able to read 1.02.1 databases because of the new
system columns.

This patch does several things.  It copies nulls out as \N, so they can
be distinguished from '' strings.  It fixes a problem where backslashes
in the input stream were not output as double-backslashes.  Without this
patch, backslashes copied out were deleted upon input, or interpreted as
special characters.  Third, input is now terminated by backslash-period.
This can not be part of a normal input stream.

I tested this by creating a database with all sorts of nulls, backslash,
and period fields and dumped the database and reloaded into a new
database and compared them.

Submitted by: Bruce
This patch can be installed as part of 1.02.1 so people can properly 1996-08-14T05:33:11+00:00 Marc G. Fournier scrappy@hub.org 1996-08-14T05:33:11+00:00 e7a110b418f557d768d7d6bfe595268f092201bc pg_dump and load to 2.0. I haven't gotten any feedback on whether people want it, so I am submitting it for others to decide. I would recommend an install in 1.02.1. I had said that the 2.0 pg_dump could dump a 1.02.1 database, but I was wrong. The copy is actually performed by the backend, and the 2.0 database will not be able to read 1.02.1 databases because of the new system columns. This patch does several things. It copies nulls out as \N, so they can be distinguished from '' strings. It fixes a problem where backslashes in the input stream were not output as double-backslashes. Without this patch, backslashes copied out were deleted upon input, or interpreted as special characters. Third, input is now terminated by backslash-period. This can not be part of a normal input stream. I tested this by creating a database with all sorts of nulls, backslash, and period fields and dumped the database and reloaded into a new database and compared them. Submitted by: Bruce 
pg_dump and load to 2.0.  I haven't gotten any feedback on whether
people want it, so I am submitting it for others to decide.  I would
recommend an install in 1.02.1.

I had said that the 2.0 pg_dump could dump a 1.02.1 database, but I was
wrong.  The copy is actually performed by the backend, and the 2.0
database will not be able to read 1.02.1 databases because of the new
system columns.

This patch does several things.  It copies nulls out as \N, so they can
be distinguished from '' strings.  It fixes a problem where backslashes
in the input stream were not output as double-backslashes.  Without this
patch, backslashes copied out were deleted upon input, or interpreted as
special characters.  Third, input is now terminated by backslash-period.
This can not be part of a normal input stream.

I tested this by creating a database with all sorts of nulls, backslash,
and period fields and dumped the database and reloaded into a new
database and compared them.

Submitted by: Bruce
I grabbed the latest version of the source code via sup this morning, 1996-08-14T05:03:47+00:00 Marc G. Fournier scrappy@hub.org 1996-08-14T05:03:47+00:00 15a645014a67f02206ffb34f65557acbd49fd54d and found out that one of the patches is a show stopper for compiling under a strict ansi package. Please make sure the following fix makes it into the 1.02.1 release... Thanks. -Kurt 
and found out that one of the patches is a show stopper for
compiling under a strict ansi package.

Please make sure the following fix makes it into the 1.02.1
release...

Thanks.

-Kurt
This is a fix to be included in 1.02.1. It adds a tip for people 1996-08-14T05:01:53+00:00 Marc G. Fournier scrappy@hub.org 1996-08-14T05:01:53+00:00 988a9adfbd28ab8b518c05ac6495cefed5959df5 getting semaphore or shared memory errors. Submitted by: bryanh@giraffe.netgate.net (Bryan Henderson) 
getting semaphore or shared memory errors.

Submitted by: bryanh@giraffe.netgate.net (Bryan Henderson)
| 1996-08-14T04:56:55+00:00 Marc G. Fournier scrappy@hub.org 1996-08-14T04:56:55+00:00 011ee13131f6fa2f6dbafd3827b70d051cb28f64 |We're all too familiar with psql's "no response from backend" message. |Users can't tell what this means, and psql continues prompting for |commands after it even though the backend is dead and no commands can |succeed. It eventually dies on a signal when the dead socket fills |up. I extended the message to offer a better explanation and made |psql exit when it finds the backend is dead. | |I also added a short message and newline when the user does a ctl-D so |it doesn't mess up the terminal display. | | Submitted by: Bryan Henderson <bryanh@giraffe.netgate.net> 
|We're all too familiar with psql's "no response from backend" message.
|Users can't tell what this means, and psql continues prompting for
|commands after it even though the backend is dead and no commands can
|succeed.  It eventually dies on a signal when the dead socket fills
|up.  I extended the message to offer a better explanation and made
|psql exit when it finds the backend is dead.
|
|I also added a short message and newline when the user does a ctl-D so
|it doesn't mess up the terminal display.
|
|

Submitted by: Bryan Henderson <bryanh@giraffe.netgate.net>
Here's a small makefile patch that corrects the following bug: The makefiles 1996-08-14T04:54:45+00:00 Marc G. Fournier scrappy@hub.org 1996-08-14T04:54:45+00:00 6b9ecd83484e5e4c37fd59b29f83a10e9a5430d9 don't indicate that the libpq.a library is a dependency of all the /bin programs. So if the library changes, the /bin programs don't get remade. Submitted by: Bryan Henderson <bryanh@giraffe.netgate.net> 
don't indicate that the libpq.a library is a dependency of all the /bin
programs.  So if the library changes, the /bin programs don't get remade.

Submitted by: Bryan Henderson <bryanh@giraffe.netgate.net>
The following patch makes postmaster -D work. -D specifies a different PGDATA 1996-08-14T04:51:34+00:00 Marc G. Fournier scrappy@hub.org 1996-08-14T04:51:34+00:00 80d0c4ffd351436c9e9480935e540d1413033aff directory. The code that looks for the pg_hba file doesn't use it, though, so the postmaster uses the wrong pg_hba file. Also, when the postmaster looks in one directory and the user thinks it is looking in another directory, the error messages don't give enough information to solve the problem. I extended the error message for this. Submitted by: Bryan Henderson <bryanh@giraffe.netgate.net> 
directory.  The code that looks for the pg_hba file doesn't use it, though,
so the postmaster uses the wrong pg_hba file.  Also, when the postmaster
looks in one directory and the user thinks it is looking in another
directory, the error messages don't give enough information to solve the
problem.  I extended the error message for this.


Submitted by: Bryan Henderson <bryanh@giraffe.netgate.net>
I have attached a minor update for the Postgres make files. This update 1996-08-13T07:48:33+00:00 Marc G. Fournier scrappy@hub.org 1996-08-13T07:48:33+00:00 ca5db6cab1107ab177203b7aef80532ac99fdea6 does 2 things: 1) Make it hard to not notice the make failed. (As you recall, someone on the mailing list had this problem. I've had it to some extent myself). The 1.02 make files continue with the next subdirectory when a make in a subdirectory fails. The patch makes the make stop in the conventional way when a submake fails. It also adds a reassuring message when the make succeeds and adds a note to the INSTALL file to expect it. 2) Include loader flags on all invocations of the linker. The 1.02 make files omit the $(LDFLAGS) on some of the linker invocations. On my system, I need one of those flags just to make it invoke the proper version of the compiler/linker, so LDFLAGS has to be everywhere. Submitted by: Bryan Henderson <bryanh@giraffe.netgate.net> 
does 2 things:

1) Make it hard to not notice the make failed.  (As you recall, someone on
   the mailing list had this problem.  I've had it to some extent myself).

    The 1.02 make files continue with the next subdirectory when a make
    in a subdirectory fails.  The patch makes the make stop in the
    conventional way when a submake fails.  It also adds a reassuring message
    when the make succeeds and adds a note to the INSTALL file to expect it.

2) Include loader flags on all invocations of the linker.

   The 1.02 make files omit the $(LDFLAGS) on some of the linker invocations.
   On my system, I need one of those flags just to make it invoke the proper
   version of the compiler/linker, so LDFLAGS has to be everywhere.

Submitted by: Bryan Henderson <bryanh@giraffe.netgate.net>
More code cleanups 1996-08-13T01:36:50+00:00 Marc G. Fournier scrappy@hub.org 1996-08-13T01:36:50+00:00 a721c91adebeb566dc1880630aa1627d4bb4c2aa Submitted by: darcy@druid.druid.com (D'Arcy J.M. Cain) 
Submitted by: darcy@druid.druid.com (D'Arcy J.M. Cain)