The command line usage (-h) output is pretty slim, and many interesting features were only mentioned in past release notes. This offers a central location for bin/sequel information. Currently, the explanations are fairly brief, but I'll certainly consider expanding the explanations if I get some specific feedback.
…ions and transparently handling disconnects This extension is primarily designed for users whose idle database connections are automatically disconnected from the database after a given period of time. However, it can also be used to handle all disconnects by validating connections at every checkout, though that may hurt performance significantly. This shouldn't cause any problems with transactions or special connection states, since code that relies on either isn't even yielded a connection until after the validation check has been run.
The extension allows you to create database constraints that mirror model validations when creating and altering tables. It adds validation metadata to a separate table. The plugin reads the metadata from that table, and uses it to automatically validate your models before saving. The advantage to doing so is that your validations are only specified in one place, but are enforced both at the model level and at the database level. This is better for data integrity, since it enforces the validation for all rows in the database, so changes made by external programs or via the dataset layer are still covered.
Instead of having one really long line, try to limit the release notes links to 10 per line.
…ort::Duration instances Implementation is similar to the pg_inet extension, though it uses a Regexp parser similar to the pg_range extension. This is mostly useful if you want to take intervals stored in your PostgreSQL database and use them in calculations involving ruby Time or DateTime instances. While adding adapter specs, do some minor cleanup using Database#extension instead of Sequel.extension.
…tors and functions This is modeled after the pg_array_ops and pg_hstore_ops extensions. While here, cleanup the plugins page for better consistency in the extension descriptions.
… (1) OR col IS NULL This has been requested a couple times in the last year. I don't think it's a good idea by default, which is why it's being implemented as an extension.
Range types are a new feature in PostgreSQL 9.2. They are similar to ruby's Range class, but significantly more flexible. Because not all PostgreSQL Ranges can be converted to ruby Range objects, the PGRange class is not a DelegateClass of Range, but a plain subclass of Object. However, in many cases it acts similarly to a delegate class, as least if the PGRange can be represented by a ruby Range. Otherwise, this extension is similar to the other Sequel pg_* extensions.
…ct attempt to return a string suitable for eval This extension is definitely not bullet proof, as there are a lot of cases it does not handle. However, in most simple cases it allows you to take an arbitrary Sequel expression and have inspect on it return a string that when evaled will produce an equivalent object.
ActiveRecord added this support recently, and I think it's a worthwhile extension to have.
…do eager loading This behavior has been requested by multiple people over the years. I've always been against changing having all call a method other than each for eager loading. I just recently thought of this approach, which doesn't require any changes to the core of Sequel.
…l strings in select, group, and order methods Sequel's default behavior for these methods, while generally consistent internally, is not consistent with the filter handling, and I think the filter handling is much more user friendly. If there ever is a Sequel 4, it will definitely act this way by default. For SELECT, I sort of understand the default, since selecting literal strings can have some uses. However, since Sequel uses hashes and literal strings without aliases aren't really a good idea (since you can't control the identifier used), that use case is going to be very uncommon. Both GROUP and ORDER don't appear to accept non-integer constants on PostgreSQL (though SQLite accepts them), so I can't imagine any breakage there. While the usage of literal strings leads to less database independent code and less opportunities for introspection, it's not necessarily a bad thing in all use cases. This makes it easier to use literal strings in SELECT, GROUP, and ORDER without the core extensions' String#lit or Sequel.lit.
This is a lot nicer than just directing them to the directory index page.
… loaded by default) This moves the core_sql.rb file into a real extension that is loaded by Sequel.extension. For backwards compatibility, this extension is still loaded by default.
…ving columns/expressions from a dataset selection I don't think this will be used often enough to go into core Sequel, and it also has some corner cases that can't be handled correctly. However, some people have been asking for it, and it's not the simplest thing to get correct by hand even for the cases it does handle correctly, so I think shipping this extension with Sequel makes sense.
…eful for model tables that don't change This plugin provides a major speedup for models whose underlying dataset is static. It's designed to work well with the the recently committed many_to_one_pk_lookup plugin.
…up for many_to_one associations (great with caching) This can be a major speed boost to models that have many_to_one associations to associated models that use caching, because it will generally use a cached lookup first.
…a database query This is another feature that ActiveRecord will be adding in 4.0. Basically, it's the null object pattern for datasets, so you can create a dataset that never returns any rows (or issues other queries). This is easily implemented as an extension, where Dataset#nullify just extends the cloned dataset with a module. Note that there may be corner cases on some adapters when using non-standard dataset methods. Those can be dealt with on a case by case basis.
…odels by loading cached schema information from a file This idea is taken from ActiveRecord, which will be adding the feature in 4.0. Basically, when loading a large number of models, there may be significant time spent loading the table schema for each table from the database, especially in high latency situations. To work around this, you can cheat by caching the information to a file, and then loading the cached file instead of querying the database for each table/model, which is what this extension does. To make it easy to generate the cached schema files, an -S option is being added to bin/sequel that creates the cached schema dump file. It's up to the application to use load_schema_cache to preload the schema cache.
…ctions and operators Same idea here as pg_array_ops, but this is for hstore operators and functions instead of array operators and functions.
…value table) type hstore is an extension that ships with PostgreSQL that allows you to store a key/value table inside a single column, where keys and values are both strings (well, values can be NULL). The implementation is similar to the pg_array extension, using a DelegateClass approach, with a hash used for backing. Since hstore only uses string keys and values, we need to override a lot of methods to force input keys/values to strings appropriately. Just like pg_array, add a DatasetMethods module for handling schema parsing/typecasting, and bound argument support in the native adapter. Thanks to pvh's sequel-hstore for the idea behind the parser, though I significantly changed the implementation.