v.1.0.5

Added Synchronous Transactions feature to allow enforcing strict sequence of queries execution inside transactions when it is needed.

• Tests added to cover Synchronous Transactions functionality.
• Documentation updates for the new feature.

v.1.0.4

• Implemented feature #18: consistent error handling when calling functions;
• Made query and function execution more strict - checking that neither are done with an empty query/function name;
• Small code + error message refactoring;
• Adding new tests to cover #18.

v.1.0.3

queryRaw

This update is in response to issue #17, being unable to access value of rowCount after UPDATE/INSERT/DELETE execution.

The solution is however much broader, and covers any situation when accessing the Result object provided by PG is preferable, as opposed to just the rows of data that's returned.

The API has been extended with method queryRaw(query, values) to bypass any result verification and resolve with the original Result object passed from PG. This new method can also be useful for those trying to move from node-postgres to promises for an existing project.

And as for rowCount in particular, here's how you can do it now:

// delete all inactive users;
db.queryRaw("delete from users where active = $1", false)
    .then(function (result) {
        console.log(result.rowCount); // print how many records were deleted;
    }, function (reason) {
        console.log(reason); // print error;
    });

A few new tests have been added to cover the update.

v.1.0.2

Fixing an issue introduced with changes in 1.0.1: When a query rejected because of an issue with query formatting, the global error handler was supposed to receive the parameters in its error context, but it didn't.

A test was added to cover this case.

v.1.0.1

Improved error reporting for queries

When queries were rejected because of the mismatch between the expected result and the actual result, or because of invalid parameters passed, those rejects were not reported into the global error handler. Instead, they were just rejected, with the optional query string concatenated with the error message. This is no longer the case.

Any reject during the query execution is now part of the global error handling mechanism. When a query is rejected, it is immediately reported into the global error handler, along with all the context details available. For that reason, the reject messages were made shorter, with just the error itself, while such detail as the query is now part of the error context that's reported globally.

A number of tests have been added to cover the additional error notifications.

v.1.0.0

Official Release

This release is to signify that the library has reached its production-ready status, being fully tested and feature-complete. Other than that, it carries no functional change over 0.9.8.

It has been a lot of fun developing this library, while learning from the process, as it was also my first project on GitHub.

I don't know how much time I will be able to allocate maintaining it from now on, but I feel confident now handing it over to the developers community.

I wrote this library because at the time I could not find any good promise-based approach to using PostgreSQL, and it helped me a lot while working on a large project, so I decided to share it with everybody, though in the end it grew into something far better than what I initially intended.

I hope it will help many others.

Vitaly.

v.0.9.8

Extended numeric formatting

Numbers used to be formatted and injected directly, without any special treatment. From now on the library properly formats such special values as NaN, +Infinity and -Infinity into their PostgreSQL form.

Method as.number(value) has been added to the protocol.

Native JSON support

Up until now JSON columns could be set only by serializing objects with JSON.stringify, while any object (non-null and non-Date) was rejected when encountered as an array element or as an object property.

In order to simplify this, this library will now automatically serialize any such object into a JSON string, while also fixing single-quote symbols and wrapping it up in single quotes.

Method as.json(value, raw) has been added to the protocol.

Other changes

• Many tests have been added to test all the new changes.
• Code refactoring and documentation updates.

v.0.9.7

Added Protocol Extensibility feature - event extend, so you can extend the existing access protocol to best suit the needs of your application.

Other changes include:

• Added testing against the most recent stable version of IO.js;
• Added a few new tests;
• Code documentation and refactoring.

v.0.9.6

This release fixes behaviour of the library when trying to use unset raw-text variables.

When a raw-text variable had value null or undefined, the library was converting it into null, which is logically incorrect, because the library cannot make any assumption about how to interpret null/undefined for the raw text, as it entirely depends on the case where it is used.

The only logical thing for the library to do in such cases is to throw an error, which it now does, with the error text:

Values null/undefined cannot be used as raw text.

Other changes:

• Added tests covering the error added.

A summary of what the new raw-text variables do as opposed to the regular variables:

• They are defined using syntax: $1^, $2^, etc... and ${propName^}, i.e. symbol ^ appended to the variable name;
• No replacement of single-quote ' with two is done on them, and no pre-processing at all for that matter;
• They do not wrap text into single quotes, using it exactly as is;
• They throw an error when the variable's value is null or undefined.

In all, they add a great flexibility to query formatting, though can break it just as easily, if not handled with care.

P.S. Any feedback on the feature is much appreciated.

v.0.9.5

This release is a quick change for the new feature introduced in 0.9.4 - stripped variable values.

It occurred to me, after extensive testing, that stripping a variable off its quotes isn't sufficient in some cases when injecting pre-formatted text. There must be no preprocessing on the text at all, including no replacement of single-quote ' with two, because it does break things for the raw text.

A good example would be when injecting pre-formatted filters, which are likely to contain single-quote symbols in them.

Now when using the syntax of $1^ or ${propName^}, no preprocessing will be done on the injected text whatsoever. And if such text may contain single-quote symbol ', it is your responsibility to replace each of them with two single-quotes where it is needed, which can be done with the following code:

txt = txt.replace(/'/g, "''");

The API and documentation have been updated everywhere to follow this changed logic:

• as.text(value, raw);
• as.date(value, raw);
• etc...

UPDATE:: An omission will be fixed in 0.9.6 regarding the raw-text values. In 0.9.5, if you try to use a variable as raw text, it will inject null, if the variable value is null or undefined. In 0.9.6 an error will be thrown in such cases, because it is not logical for raw-text variables to handle those values. Error message will be something like this: Values null/undefined cannot be used as raw text.. This makes raw-text variables a tad more dangerous, and they should be used with care.