| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
A few tests use u'' unicode literals which are not
supported in Python versions 3.1 and 3.2.
|
|
|
|
|
|
| |
("C", whatever that means,
cannot find meaning of this anywhere in Postgresql documentation) seems to work
|
|\
| |
| | |
Support for Postgres range types.
|
| | |
|
| |
| |
| |
| | |
http://www.postgresql.org/docs/9.2/interactive/functions-range.html
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
One can use this to emit statements, which can not be
executed within a transaction (e. g. CREATE DATABASE):
from sqlalchemy import create_engine
eng = create_engine('postgresql://test:test@localhost/test')
conn = eng.connect().execution_options(isolation_level='AUTOCOMMIT')
conn.execute('CREATE DATABASE test2;')
Fixes issue #2072.
|
|
|
|
| |
- fix test
|
|
|
|
|
| |
add unicode encoding for py2k for the non-native hstore, pullreq for
native psycopg2 support coming....
|
| |
|
|\ |
|
| |
| |
| |
| | |
run on its own.
|
| | |
|
|/
|
|
| |
- went through examples/ and cleaned out excess list() calls
|
| |
|
|
|
|
| |
unconditonally instead so that it works in all cases.
|
|
|
|
|
|
|
|
|
|
| |
input types of sets, generators, etc. but only when a dimension
is specified for the ARRAY; otherwise, the dialect
needs to peek inside of "arr[0]" to guess how many
dimensions are in use. If this occurs with a non
list/tuple type, the error message is now informative
and directs to specify a dimension for the ARRAY.
[ticket:2681]
|
| |
|
| |
|
|
|
|
|
|
|
| |
function syntax, renders as "SUBSTRING(x FROM y FOR z)"
when regular ``func.substring()`` is used.
Also in 0.7.11. Courtesy Gunnlaugur Por Briem.
[ticket:2676]
|
|
|
|
|
|
| |
- other cleanup
- don't need compat.decimal, that approach never panned out. hopefully
outside libs aren't pulling it in, they shouldn't be
|
| |
|
| |
|
|
|
|
|
| |
inside of an :func:`.expression.insert` construct would produce an
error regarding a parameter issue in the ``self_group()`` method.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- update "not supported" messages for empty inserts, mutlivalue inserts
- rework the ValuesBase approach for multiple value sets so that stmt.parameters
does store a list for multiple values; the _has_multiple_parameters flag now indicates
which of the two modes the statement is within. it now raises exceptions if a subsequent
call to values() attempts to call a ValuesBase with one mode in the style of the other
mode; that is, you can't switch a single- or multi- valued ValuesBase to the other mode,
and also if a multiple value is passed simultaneously with a kwargs set.
Added tests for these error conditions
- Calling values() multiple times in multivalue mode now extends the parameter list to
include the new parameter sets.
- add error/test if multiple *args were passed to ValuesBase.values()
- rework the compiler approach for multivalue inserts, back to where
_get_colparams() returns the same list of (column, value) as before, thereby
maintaining the identical number of append() and other calls when multivalue
is not enabled. In the case of multivalue, it makes a last-minute switch to return
a list of lists instead of the single list. As it constructs the additional lists, the inline
defaults and other calculated default parameters of the first parameter
set are copied into the newly generated lists so that these features continue
to function for a multivalue insert. Multivalue inserts now add no additional
function calls to the compilation for regular insert constructs.
- parameter lists for multivalue inserts now includes an integer index for all
parameter sets.
- add detailed documentation for ValuesBase.values(), including careful wording
to describe the difference between multiple values and an executemany() call.
- add a test for multivalue insert + returning - it works !
- remove the very old/never used "postgresql_returning"/"firebird_returning" flags.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
:class:`.ColumnElement` would go into an endless loop, if
:meth:`.ColumnOperators.__getitem__` were implemented.
A new NotImplementedError is emitted via ``__iter__()``.
|
|
|
|
| |
- don't need a custom exception here, just use ValueError
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
become an externally usable package but still remains within the main sqlalchemy parent package.
in this system, we use kind of an ugly hack to get the noseplugin imported outside of the
"sqlalchemy" package, while still making it available within sqlalchemy for usage by
third party libraries.
|
|
|
|
|
|
|
| |
are now returned in the order in which the constraint
itself defines them, rather than how the table
orders them. Courtesy Gunnlaugur Por Briem.
[ticket:2531].
|
|
|
|
|
| |
- some fixes to the patch to handle empty args, whitespace
- changelog clarifies where this API fits at the moment
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
more lenient as to the table
being updated. Plain Table objects are better
supported now, and additional a joined-inheritance
subclass may be used with update(); the subclass
table will be the target of the update,
and if the parent table is referenced in the
WHERE clause, the compiler will call upon
UPDATE..FROM syntax as allowed by the dialect
to satisfy the WHERE clause. Target columns
must still be in the target table i.e.
does not support MySQL's multi-table update
feature (even though this is in Core).
PG's DELETE..USING is also not available
in Core yet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the `getitem` operator, i.e. the bracket
operator in Python. This is used at first
to provide index and slice behavior to the
Postgresql ARRAY type, and also provides a hook
for end-user definition of custom __getitem__
schemes which can be applied at the type
level as well as within ORM-level custom
operator schemes.
Note that this change has the effect that
descriptor-based __getitem__ schemes used by
the ORM in conjunction with synonym() or other
"descriptor-wrapped" schemes will need
to start using a custom comparator in order
to maintain this behavior.
- [feature] postgresql.ARRAY now supports
indexing and slicing. The Python [] operator
is available on all SQL expressions that are
of type ARRAY; integer or simple slices can be
passed. The slices can also be used on the
assignment side in the SET clause of an UPDATE
statement by passing them into Update.values();
see the docs for examples.
- [feature] Added new "array literal" construct
postgresql.array(). Basically a "tuple" that
renders as ARRAY[1,2,3].
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ForeignKeyConstraint, courtesy Ryan Kelly.
[ticket:2502]
- [feature] Added support for DELETE and UPDATE from
an alias of a table, which would assumedly
be related to itself elsewhere in the query,
courtesy Ryan Kelly. [ticket:2507]
- [feature] Added support for the Postgresql ONLY
keyword, which can appear corresponding to a
table in a SELECT, UPDATE, or DELETE statement.
The phrase is established using with_hint().
Courtesy Ryan Kelly [ticket:2506]
|
| |
|
|
|
|
|
|
|
|
| |
"dimension" argument, will assign a specific
number of dimensions to the array which will
render in DDL as ARRAY[][]..., also improves
performance of bind/result processing.
[ticket:2441]
|
| |
|
|
|
|
| |
used by Alembic, to escape % signs with %%.
|
|
|
|
|
|
|
|
| |
CompileException for all type/statement compilation
issues, instead of InvalidRequestError or ArgumentError.
The DDL for CREATE TABLE will re-raise
CompileExceptions to include table/column information
for the problematic column. [ticket:2361]
|
|
|
|
|
|
|
|
|
| |
to pg.ENUM. When False, no CREATE/DROP or
checking for the type will be performed as part
of a table create/drop event; only the
create()/drop)() methods called directly
will do this. Helps with Alembic "offline"
scripts.
|
|
|
|
|
|
|
|
|
| |
particular name was processed
during a create/drop sequence. This allows
a create/drop sequence to work without any
calls to "checkfirst", and also means with
"checkfirst" turned on it only needs to
check for the ENUM once. [ticket:2311]
|
|
|
|
|
|
| |
when the postgresql+psycopg2 dialect is used;
calls the psycopg2 set_client_encoding() method
with the value upon connect. [ticket:1839]
|