v.0.9.4

Added support for stripped variable values: a variable name now can be appended with symbol ^ to indicate that if it is text-like (text or Date), its value is to be injected as is, without being wrapped in single quotes:

$1^, $2^, etc... or ${varName^}

This is to allow for special-case variable formatting, like in the following examples:

// injecting "John" name without quotes:
query("...WHERE name LIKE '%$1^%'", "John");

// injecting value of property 'name' without quotes:
query("...WHERE name LIKE '%${name^}%'", {name: "John"});

// injecting a CSV-formatted string without quotes:
query("...WHERE id IN($1^)", pgp.as.csv([1,2,3,4])); 

Methods as.text(value, strip) and as.date(value, strip) have received new parameter-flag strip as they are the ones handling the formatting.

I also started working on the Learn by Example tutorial, to help first time users.

Other changes include:

• Improved tests and test instructions;
• New tests were added to cover stripped variable functionality;
• Documentation updates.

v.0.9.3

A change was made in support for PostgreSQL Array Type, the feature that was first introduced with 0.9.2. The change is in the syntax of the output value format to use the alternative, open array format of array[] instead of the string format of '{}', because the latter requires use of double quotes around strings, making it inconsistent with the default single-quotes for strings, and as a result arrays of strings didn’t format properly.

Other changes made in the library:

• Boolean format was changed from the capitalized form of TRUE/FALSE to true/false, for consistency with everything else in the library;
• A few changes have been made in error handling: improved error messages and English;
• Documentation updates, TOC fixed;
• Improved test coverage.

It is worth noting that while still dealing with issue #14, it is generally a good idea for anyone using the library to also use the promise override feature, switching over to the promise of your choice, so that your code is never affected by issues related to the default promise used by the library.

v.0.9.2

Adding support for PostgreSQL Array Types of any depth:

db.query("insert into data values(${vector})", {
    vector: [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
});
// will execute:
// insert into data values('{{1,2,3},{4,5,6},{7,8,9}}')
// expected database type: int[][]

Other changes:

• Substantial update to the official documentation;
• Added tests for the new array types support;
• Refactoring and reorganizing many tests;
• Updated package dependencies;

v.0.9.1

This release is for the quality improvement only, after some major changes in the previous release:

• code refactoring and documentation;
• official documentation updates;
• new tests added for the events support;

v.0.9.0

This release is a major re-work on the events mechanism, with one breaking change - event query, and many new features to improve event reporting to the client.

And while the main documentation has been updated for all the changes, it is too brief and misses the level of detail that the event logging deserves. This shortage will be addressed in the upcoming releases.

Main points:

• parameters for event query have changed (breaking change);
• added event transact to receive transaction start/finish events;

For events query, error and transact, parameter ctx (transaction context) is supported, which provides such useful details as:

• transaction start time;
• transaction finish time;
• success flag, if finished;
• result, if finished: error or data, depending on success flag;

It is now possible to tag a transaction using any parameter - a string or an object, or even a function, if needs to be, and then use it at any point either in event logging or even the transaction itself:

db.tx("myTransaction", function(t){
    console.log(t.ctx.tag); // will print 'myTransaction';
    return promise.resolve('success');
});

Each transaction now provides its own context, property ctx, which has the properties listed above, as well as property tag, which is the tag passed into the transaction.

It is now possible to isolate simple query logging from transaction query logging. When query event is reported, one can check whether it is part of a transaction or not.

Transaction context is now everywhere where it is applicable. And tagged transactions let you logically group logging, for much easier events reading.

v.0.8.5

This release is a rewrite of what was done for 0.8.4, to widen the scope of error reporting to transactions and query formatting, which in turn resulted in changing the format of the error notification - property options.error

See property error documentation in Initialization Options.

As part of improving the error handling, Named Transactions support was added, so that when a transaction callback throws an error, the error is reported along with the transaction name. This resulted in extending the transaction usage, so they can also be called like this:

db.tx("myTransaction", function(ctx){
    // callback implementation;
});

The previous syntax, with just the callback as parameter is still supported.

v.0.8.4

Added global error handling support via property error in Initialization Options, to make it easy logging errors during query execution.

The new property has been well documented in Initialization Options.

UPDATE: This release caused issues related to error handling inside transactions. A new release will be out shortly to address those issues.

v.0.8.3

• extensive code refactoring + documentation;
• adding new tests for Named Parameters

v.0.8.2

This update fixes issue #12, to support symbol $ in Named Parameters.

Tests and documentation have been updated for this change.

v.0.8.1

This follow-up release fixes one issue with the new Named Parameters feature:

It didn't distinguish a missing object property from when its value was set to be undefined, providing null value in both cases.

So now, while property values null and undefined are both formatted as null, an error is thrown when the property doesn't exist at all.

Other changes included:

• tests were added for the new logic;
• many updates in the documentation;
• code refactoring and documentation.