versions of gcc.  We don't really need to explicitly test the limits
anyway, just reverse-convert and see if we get the same answer.

coercing OID literals to OID in its queries.  Depending on the query
and the server version, this could cause failures for OIDs over 2 billion.

max_connections.

for them, and making them just wastes time during backend startup/shutdown.
Also, remove compile-time MAXBACKENDS limit per long-ago proposal.
You can now set MaxBackends as high as your kernel can stand without
any reconfiguration/recompilation.

>
>> On Mon, 3 Sep 2001 22:01:17 -0500, you wrote:
>>     public boolean isWritable(int column) throws SQLException
>>     {
>>         return !isReadOnly(column);
>>     }

Actually, I think this change has a consequence for this method
in the same class:

    public boolean isDefinitelyWritable(int column)
        throws SQLException
    {
        return isWritable(column);
    }

This is from the JDBC spec
(http://java.sun.com/j2se/1.3/docs/api/java/sql/ResultSetMetaData.html):

  isReadOnly() - Indicates whether the designated column is
definitely not writable.

  isWritable() - Indicates whether it is possible for a write on
the designated column to succeed.

  isDefinitelyWritable() - Indicates whether a write on the
designated column will definitely succeed.

At this time we don't really implement the fine semantics of
these methods. I would suggest the following defaults:

  isReadOnly()             false
  isWritable()             true
  isDefinitelyWritable()   false

And that would mean that your patch is correct, but
isDefinitelyWritable() would need to be patched accordingly:

    public boolean isDefinitelyWritable(int column)
        throws SQLException
    {
        return false;
    }

Again, both in jdbc1 and jdbc2.

Regards,
Ren? Pijlman <rene@lab.applinet.nl>

>public boolean isWritable(int column) throws SQLException
>{
>        if (isReadOnly(column))
>                return true;
>        else
>                return false;
>}

The author probably intended:

    public boolean isWritable(int column) throws SQLException
    {
        return !isReadOnly(column);
    }

And if he would have coded it this way he wouldn't have made
this mistake :-)

>hence, isWritable() will always return false. this is something
>of a problem :)

Why exactly? In a way, true is just as incorrect as false, and
perhaps it should throw "not implemented". But I guess that
would be too non-backwardly-compatible.

>let me know if i can provide further information.

Will you submit a patch?

Regards,
Ren? Pijlman <rene@lab.applinet.nl>

> new files). I'm attaching those two files below.
>
> Regards
> Mikhail Terekhov

Thanks. However, I seem to have left a single debug statement in there :-(

Here's a patch to remove it.

Vianen, Jeroen van

written a generic framework of rules that the contrib makefiles can
use instead of writing their own each time.  You only need to set a few
variables and off you go.

man page to the Programmer's Guide.

-------------------------------------------------------------------
Subject: Re: [PATCHES] encoding names
From: Karel Zak <zakkr@zf.jcu.cz>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: pgsql-patches <pgsql-patches@postgresql.org>
Date: Fri, 31 Aug 2001 17:24:38 +0200

On Thu, Aug 30, 2001 at 01:30:40AM +0200, Peter Eisentraut wrote:
> > 		- convert encoding 'name' to 'id'
>
> I thought we decided not to add functions returning "new" names until we
> know exactly what the new names should be, and pending schema

 Ok, the patch not to add functions.

> better
>
>     ...(): encoding name too long

 Fixed.

 I found new bug in command/variable.c in parse_client_encoding(), nobody
probably never see this error:

if (pg_set_client_encoding(encoding))
{
	elog(ERROR, "Conversion between %s and %s is not supported",
                     value, GetDatabaseEncodingName());
}

because pg_set_client_encoding() returns -1 for error and 0 as true.
It's fixed too.

 IMHO it can be apply.

		Karel
PS:

    * following files are renamed:

src/utils/mb/Unicode/KOI8_to_utf8.map  -->
        src/utils/mb/Unicode/koi8r_to_utf8.map

src/utils/mb/Unicode/WIN_to_utf8.map  -->
        src/utils/mb/Unicode/win1251_to_utf8.map

src/utils/mb/Unicode/utf8_to_KOI8.map -->
        src/utils/mb/Unicode/utf8_to_koi8r.map

src/utils/mb/Unicode/utf8_to_WIN.map -->
        src/utils/mb/Unicode/utf8_to_win1251.map

   * new file:

src/utils/mb/encname.c

   * removed file:

src/utils/mb/common.c

--
 Karel Zak  <zakkr@zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

 C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz

> pam_strerror() should be used a few more times, rather than just saying
> "Error!".  Also, the configure.in snippet seems wrong.  You add
> -I$pam_prefix/include/security to $INCLUDES and then you #include
> <security/pam_appl.h>.  This whole thing is probably unnecessary, since
> PAM is a system library on the systems where it exists, so the headers
> and libraries are found automatically, unlike OpenSSL and
> Kerberos.

See attached revised patch. (I'm sure the configure.in stuff can be done
right/better, I'm just not enough of a autoconf guru to know what to
change it to.)

Dominic J. Eidson

 - new millisecond (ms) and microsecond (us) support
 - more robus parsing from string - used is separator checking for
   non-exact formats like to_date('2001-9-1', 'YYYY-MM-DD')
 - SGML docs are included

Karel Zak

Marko Kreen

flawed in the following ways:

1. Only returned columns that had a default value defined, rather than all
columns in a table
2. Used 2 * N + 1 queries to find out attributes, comments and typenames
for N columns.

By using some outer join syntax it is possible to retrieve all necessary
information in just one SQL statement. This means this version is only
suitable for PostgreSQL >= 7.1. Don't know whether that's a problem.

I've tested this function with current sources and 7.1.3 and patched both
jdbc1 and jdbc2. I haven't compiled nor tested the jdbc1 version though, as
I have no JDK 1.1 available.

Note the discussion in http://fts.postgresql.org/db/mw/msg.html?mid=1029626
regarding differences in obtaining comments on database object in 7.1 and
7.2. I was unable to use the following syntax (or similar ones):

select
     ...,
     description
from
     ...
     left outer join col_description(a.attrelid, a.attnum) description
order by
     c.relname, a.attnum;

(the error was parse error at or near '(') so I had to paste the actual
code for the col_description function into the left outer join. Maybe
someone who is more knowledgable about outer joins might provide me with a
better SQL statement.

Jeroen van Vianen

includes windows.h, which #defines ERROR to 0. PostgreSQL's logging functions
define ERROR to -1. This patch redefines ERROR to -1 to avoid current or
future breakage of the logging functions.

Gerhard H?ring

> > -patches as well.
>
> The -Bdynamic probably ought to disappear.

That was there already, but I have no objections.  I was trying to
make minimal changes.

Larry Rosenman

I believe this will fix peter_e's problen with gcc.

Larry Rosenman

the JDBC driver.

I've done this by extracting it into a new method object called
QueryExecutor (should go into org/postgresql/core/) and then taking it
apart into different methods in that class.

A short summary:

* Extracted ExecSQL() from Connection into a method object called
  QueryExecutor.

* Moved ReceiveFields() from Connection to QueryExecutor.

* Extracted parts of the original ExecSQL() method body into smaller
  methods on QueryExecutor.

* Bug fix: The instance variable "pid" in Connection was used in two
  places with different meaning. Both were probably in dead code, but it's
  fixed anyway.

Anders Bengtsson

for the changed files and a few new files:
- test/jdbc2/BatchExecuteTest.java
- util/MessageTranslator.java
- jdbc2/PBatchUpdateException.java

As an aside, is this the best way to submit a patch consisting
of both changed and new files? Or is there a smarter cvs command
which gets them all in one patch file?

This patch fixes batch processing in the JDBC driver to be
JDBC-2 compliant. Specifically, the changes introduced by this
patch are:

1) Statement.executeBatch() no longer commits or rolls back a
transaction, as this is not prescribed by the JDBC spec. Its up
to the application to disable autocommit and to commit or
rollback the transaction. Where JDBC talks about "executing the
statements as a unit", it means executing the statements in one
round trip to the backend for better performance, it does not
mean executing the statements in a transaction.

2) Statement.executeBatch() now throws a BatchUpdateException()
as required by the JDBC spec. The significance of this is that
the receiver of the exception gets the updateCounts of the
commands that succeeded before the error occurred. In order for
the messages to be translatable, java.sql.BatchUpdateException
is extended by org.postgresql.jdbc2.PBatchUpdateException() and
the localization code is factored out from
org.postgresql.util.PSQLException to a separate singleton class
org.postgresql.util.MessageTranslator.

3) When there is no batch or there are 0 statements in the batch
when Statement.executeBatch() is called, do not throw an
SQLException, but silently do nothing and return an update count
array of length 0. The JDBC spec says "Throws an SQLException if
the driver does not support batch statements", which is clearly
not the case. See testExecuteEmptyBatch() in
BatchExecuteTest.java for an example. The message
postgresql.stat.batch.empty is removed from the language
specific properties files.

4) When Statement.executeBatch() is performed, reset the
statement's list of batch commands to empty. The JDBC spec isn't
100% clear about this. This behaviour is only documented in the
Java tutorial
(http://java.sun.com/docs/books/tutorial/jdbc/jdbc2dot0/batchupdates.html).
Note that the Oracle JDBC driver also resets the statement's
list in executeBatch(), and this seems the most reasonable
interpretation.

5) A new test case is added to the JDBC test suite which tests
various aspects of batch processing. See the new file
BatchExecuteTest.java.

Regards,
Ren? Pijlman