
2008-10-04

    Npgsql2 2.0.1
    
    This version brings some minor bugfixes since 2.0 release.
    
    Fixed a bug where boolean values were being quoted. This was giving problems with edmgen tool for entityframework support.
    Fix for a date and infinity values comparison.
From patch:

"This check for Datetime.minvalue and maxvalue is needed in order to
workaround a problem when comparing date values with infinity.
This is a known issue with postgresql and it is reported here:
http://archives.postgresql.org/pgsql-general/2008-10/msg00535.php
Josh's solution to add cast is documented here:
http://pgfoundry.org/forum/message.php?msg_id=1004118"

Thanks Josh for fix idea.

[#1010488] NgsqlParameter of type containing DBNull values throws NullReferenceException. Thanks Christ Akkermans for testcase.

Changed some NpgsqlTypes namespace structs in order to get better Npgsql1 compatibility in order to have Npgsql2 included in future Mono releases. Thanks Josh Cooley for last minute fix on those changes.

Fixed SqlInsertGenerator: Add schema qualification to table name when fetching sequence values. Thanks Josh Cooley for fix.


2008-09-12
    Npgsql2 RC2
    
    This version contains some fixes and updates for latest entity framework release.
    We are already in feature freeze and not so many things were added this time.
    
    Highlights include:
    
    Npgsql2 rc2 now supports .NET 3.5 sp1 with Entity Framework support.  We support model generation by the command line edmgen.exe tool.  This requires the Npgsql be registered in the provider <DbProviderFactories> section of machine.config.
    
    A lot of fixes were done on connection pool handling. Also, when running under Mono, Npgsql wasn't using connection pool. Now it is.
    
    We added some code to better handle threadabort when executing queries with Npgsql. It isn't perfect but is much better than with previous versions.
    

2008-04-07
	Npgsql2 Beta3


	Please note: This release contains changes that will require a recompile of code using it.

New Features:

	Added support for integrated security on windows. In order to use it, just use the connection string parameter: Integrated Security=true. Thanks Brar Piening for patch!
	[#1010216] Support for array handling. Parameters can be of type T[] where T is an already supported type. In addition, parameters of a type that support IEnumerable<T> will be treated as T[], types that support IEnumerable<U> where U supports IEnumerable<T> will be treated as a two-dimensional T[] and so on (though if each U has a different number of T items the result is a jagged array and postgres will hence return an error as it doesn't support jagged arrays). The NpgsqlDbType value NpgsqlDbType.Array should be combined using binary-or to produce an array type (e.g. NpgsqlDbType.Array | NpgsqlDbType.Box is an array of box). Direct support for a type is checked first in determining correct handling so byte[] and string are threated as bytea or text by default, not as byte[] or char[] (string implements IEnumerable<char>). GetValue() will also return an array when appropriate. Support for IEnumerable<T> is write-only as the system cannot determine that you might want e.g. List<Int32> rather than Int32[], but when desired a different collection can be created from the returned array (e.g. List<Int32> myList = new List<Int32>((Int32[])reader.GetValue(0)).

	New types for representing dates and times with the extra information postgres provides beyond that available in DateTime and TimeSpan and allowing for dates outside of the range [0001-01-01T00:00:00 - 9999-12-31T23:59:59] that DateTime allows for. These are still under development and likely to be changed in the near-future, so subsequent beta releases may introduce breaking changes.

	DataReader is now loaded as-needed from the source data. This produces a considerable increase in scalability - in particular very large recordsets will now be much faster and use much less memory, and there is no longer a limit after which the provider consumes all available memory (memory usage remains very low even when reading billions of rows).

	Support for CommandBehavior.SequentialAccess. Note that because of the nature of the encoding used by postgres it is not possible to get a count of pending bytes or chars by calling GetBytes() or GetChars() with a null parameter for the buffer when SequentialAccess is being used (this issue does not affect GetBytes() or GetChars() without SequentialAccess). Beyond this issue, the normal peformance benefits of SequentialAccess are now available to Npgsql users (again, bytea of many MB in size can now be read and only the size of your buffer will affect memory consumption).

	While ADO.NET has never allowed an operation on a connection while an IDataReader is open, a side-effect of Npgsql's previous method of creating NpgsqlDataReader objects is that this would not cause an error when users did so. Now doing so will throw an InvalidOperationException as per the spec, but adding "preloadreader=true;" or "preload reader=true;" etc. to the connection string will result in a backwards-compatible mode, so that existing code taking advantage of this lenience need not suddenly break. This loses all of the performance and scalability gains of the new code so it SHOULD ONLY BE USED IN CASES WHERE EXISTING CODE HAS PROBLEMS and is for backwards-compatibility only. Internal use of datareaders uses the new method in either case. It is also notable that if you have a DataReader open, but all its results have been read, that it does not have this issue, so applications which failed to close NpgsqlDataReader objects but always read all available data will not need to use this backwards-compatibility mode (this is still strictly not allowed by the spec, so authors of such applications are advised that they may experience errors should they try to extend their applications to support other databases).

	Increased resiliance to loss of underlying connection (should e.g. postgres be restarted between Npgsql operations) and stream corruption (should e.g. a thread be aborted during read or write operations).

	Increased resiliance in the face of an unexpected value - still throws an error on Get* but survives the error.

	Dropped support for client encodings other than UTF-8. Since .NET/Mono can always convert a string to and from UTF-8, all supported postgres versions can always accept and send strings in UTF-8, and there are no values that either .NET nor postgres can use as a character that cannot be encoded in UTF-8, the only real result of allowing other encodings is to introduce the possibility of certain bugs that cannot happen with UTF-8. The handling of "ascii" was also not strictly ASCII, in a way in which handling of characters outside the range [U+0000 - U+007F] was undefined and often different betweent the client and the server. The Encoding property of NpgsqlConnectionStringBuilder is left for backwards-compatibility, but will always return "UNICODE", will silently ignore attempts to set it, and is marked as obsolete (so using it will raise warning 618).

	Changed NpgsqlConnection.PostgreSqlVersion to return a System.Version as ServerVersion offered no functionality beyond that offered by Server.Version, a class more familiar to .NET/Mono hackers, and more easily used along with other code. ServerVersion still exists for backwards compatibility, which can be implicitly cast to and from System.Version. Any use of ServerVersion will raise warning 618 on compiling. This change also removes a flaw with ServerVersion.GetHashCode() which was producing poor hash codes that made hash collisions highly likely (because this is used internally for several reasons there would be a needless performance hit if you the same application made use of two servers with different, but clashing, versions. E.g. if you connected to an 8.1.2, 8.2.1, 8.3.0 and a 8.3.1 server retrieving the correct internal information for the first three would be slowed down by their having the same hash codes).

	Removed some dead code and unused namespace imports (slight speed up on compile time).
	
	Duplication of tests for different connection string values, to catch any bugs that only occur with some settings.

	Added support for parameters explicit typing on plain queries (this support was already present when calling functions). Now when sending queries, Npgsql will send the exact typing of the parameters as specified by DbType or NpgsqlDbType enums. This will allow better type matching between client and server. Thanks Jon Hanna, Josh Cooley and Agrinei for heads up. See http://pgfoundry.org/forum/message.php?msg_id=1002944 for more info.

	Added support to search_path in connection string. Thanks Andrus Moor for patch! See here: http://pgfoundry.org/forum/message.php?msg_id=1002859 for discussion.

	Added support to property ProcessID in NpgsqlConnection.
	[#1010312] Code cleanup. Thanks Alaric Dailey for patch.

Bug fixes:
	[#1000396] CommandBehavior.SingleResult and CommandBehavior.SingleRow producing invalid SQL with some queries. While previous fixes had improved this, there are always edge-cases for which the previous method would fail, or worse would silently change the effects of a query. SingleRow and SchemaOnly now do not alter the command set (users can still use LIMIT in a natural way for commands that will only ever be used in this way), but extraneous information is skipped as efficiently as possible.
	[#1008865] Incorrect parsing of OID for lastInsertedOID.
	[#1000721] Failure on reading > 1million rows. See note on lazy-loading of datareader.
	[#1010317] GetSchemaTable() returning first result even if NextResult() has been called between first and subsequent calls.
	[#1000721] Memory Usage, ExecuteReader and > 1 Million Rows - Fixed with functionality change to load datareader as needed.
	[#1000659] Cannot pass array as a parameter to plgsql function call - Fixed with addition of array-handling support.
	[#1002776] The connection string parameter CommandTimeout does't affected on Command.CommandTimeout. Thanks Oleg Ufaev for patch.
	Npgsql used to prepend ":" to parameter names when they were added without it. This was causing problems with Entity framework and also was wrong at first place. Now Npgsql returns the name correctly. (Josh Cooley)
	Fixed problem when calling functions with inout or out parameters. They were being incorrectly added with a column list	which was complained by postgresql server: ERROR: 42601: a column definition list is only allowed for functions returning "record". See http://pgfoundry.org/forum/forum.php?thread_id=1075&forum_id=519 for discussion about this. Thanks very much to Anton Andreev (fn30762 at fmi dot uni-sofia dot bg) for his help providing test cases.
	Fixed NpgsqlSchema.GetDataSourceInformation() which was throwing exception. Thanks Patrik Husfloen (husfloen at gmail dot com) for patch.
	[#1010218] Send 'SET CLIENT_ENCODING TO UNICODE' command only if required. Thanks David Bachmann for patch.

2007-11-06


New Features:

	Added support to use '=' and ';' in connection string values. '=' are added by doubling it: == and ';' in the
	value by enclosing in single or double quotation marks, (if the value in enclosed in quotation marks, a quotation mark can be put in the value by doubling). Thanks Ben Sagal (bensagal at gmail dot com) for patch.

	New NpgsqlCopyIn and NpgsqlCopyOut classes support fast bulk data transfer with COPY FROM STDIN and COPY TO STDOUT commands as explained at http://www.postgresql.org/docs/8.2/interactive/sql-copy.html. Depending on how they are called, they consume or provide byte streams for passing data into and out of a database table (or SELECT), respectively.
	Experimental NpgsqlCopySerializer class is also provided. It takes input field values as objects. It should eventually handle encoding, buffering and different feed formats on behalf of the caller. Hopefully it will evolve into a convenient and secure method of feeding data into database and get accompanied by a deserializer.
	Note that when feeding straight to COPY FROM STDIN operation, you have to provide data using the same encoding as the server uses. Same goes for data read by COPY TO STDOUT. Also, you should be warned that data should be passed one row at a time to work around some server-side discrepancy. Thanks Kalle Hallivuori (kato at iki dot fi)

	Npgsql tests are now easier to run. Up to now, there was a hardcoded path to find nunit assemblies when running the nant tests target. Now, thanks to Gert Driesen (gert dot driesen at ardatis dot com) these assemblies are found without any hardcoded path.

	Added support for DataSourceInformation schema in NpgsqlConnection.GetSchema(string collectionName, string[]
	restrictions). Thanks Rasha (strasha at gmail dot com) for patch.

	Improved NpgsqlCommandBuilder so it now conforms to ADO.NET 2.0 standards. Thanks Rasha (strasha at gmail dot com) for patch.

	Added initial support for System.Transactions. This code is still in very early stage, so if you have any problems with it, please let us know so we can fix it as soon as possible. More info and sample code can be found in our UserManual. (Josh Cooley)

	[#1008537] New resource files - zh-CN. Added support for Chinese (Simplified). Thanks Fan (Frank) Chown (reverseark at gmail dot com) for patch!


	Bug fixes:

	[#1007697] Parameter name is not trimmed NpgsqlParameter constructor. Thanks Joren Six (sixjoren at msn dot com) for patch.

	Fixed SSL authentication by setting an static field to true: RSACryptoServiceProvider.UseMachineKeyStore = true. See https://bugzilla.novell.com/show_bug.cgi?id=MONO77559 and http://pgfoundry.org/forum/message.php?msg_id=1002377 for more info about that. Thanks Erwin Thaler (the at adv dot magwien dot gv dot at) for heads up.

	[#1003272] Queue Empty exception. Thanks Francois Payette ( francoisp at netmosphere dot net) for patch.
	[#1000847] Connection settings are parsed wrong with Turkish locale. Thanks Gokcer Gokdal (gokcergokdal at yahoo dot com) for patch.

	Fixed a possible lockup when using SyncNotification. Runtime wasn't releasing the lock fairly. See http://pgfoundry.org/forum/message.php?msg_id=1002650 for more info. Thanks Clive Simmens (cs at ctronix dot com) for heads up, tests and patch.


2007-07-03

    Npgsql2 Preview Release


    This is a preview release of Npgsql2 which supports ADO.Net 2.0 API. Note that this release may be the last release under LGPL license. So, some features may not be readily available in next release when we change to BSD license. This is due to the fact that some patches may not get its permission to be relicensed whether because the developer didn't want or can't be found. If any feature currently present won't show in next release we will let you know.

	Enjoy!

	The Npgsql Development Team
