- 27 6月, 2014 1 次提交
-
-
由 Yves Senn 提交于
-
- 22 6月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
Attempting to reduce the number of places that care about the details of how type casting occurs. We remove the type casting of the primary key in `JoinDependecy`, rather than encapsulating it. It was originally added for consistency with https://github.com/rails/rails/commit/40898c8c19fa04442fc5f8fb5daf3a8bdb9a1e03#diff-06059df8d3dee3101718fb2c01151ad0R211, but that conditional was later removed in https://github.com/rails/rails/commit/d7ddaa530fd1b94e22d745cbaf2e8a5a34ee9734. What is important is that the same row twice will have the same value for the primary key, which it will.
-
- 19 6月, 2014 1 次提交
-
-
由 Josh Sharpe 提交于
-
- 10 6月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
In some cases there is a difference between the two, we should always be doing one or the other. For convenience, `type_cast` is still a private method on type, so new types that do not need different behavior don't need to implement two methods, but it has been moved to private so it cannot be used accidentally.
-
- 06 6月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
Whiny nils is no longer a thing, so we no longer need this optimization
-
- 04 6月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
For any type that is represented as a string and then type cast, we do not need separate regular expressions for the various types. No function will match this regex. User defined types *should* match this, so that the type object can decide what to do with the value.
-
- 03 6月, 2014 4 次提交
-
-
由 Yves Senn 提交于
-
由 Sean Griffin 提交于
-
由 Yves Senn 提交于
-
由 Yves Senn 提交于
-
- 30 5月, 2014 1 次提交
-
-
由 Yves Senn 提交于
This is an intermediate solution. It is related to the refactoring @sgrif is making and will change in the future.
-
- 27 5月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
With ActiveRecord::Properties, we now have a reasonable path for users to continue to keep this behavior if they want it. This is an edge case that has added a lot of complexity to the code base.
-
- 26 5月, 2014 2 次提交
- 24 5月, 2014 3 次提交
-
-
由 Yves Senn 提交于
This mirrors the layout of abstract adapter and puts the definitions inside the `PostgreSQL` namespace (no longer under the adapter namespace). /cc @kares
-
由 Sean Griffin 提交于
-
由 Sean Griffin 提交于
-
- 23 5月, 2014 6 次提交
-
-
由 Sean Griffin 提交于
Columns and injected types no longer have any conditionals based on the format of SQL type strings! Hooray!
-
由 Sean Griffin 提交于
-
由 Sean Griffin 提交于
Ideally types will be usable without having to specify a sql type string, so we should keep the information related to parsing them on the adapter or another object.
-
-
由 Sean Griffin 提交于
We're going to want all of the benefits of the type map object for registrations, including block registration and real aliasing. Moves type name registrations to the adapter, and aliases the OIDs to the named types
-
由 Sean Griffin 提交于
Determining things like precision and scale in postgresql will require the given blocks to take additional arguments besides the OID. - Adds the ability to handle additional arguments to `TypeMap` - Passes the column type to blocks when looking up PG types
-
- 21 5月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
-
- 20 5月, 2014 2 次提交
-
-
由 Sean Griffin 提交于
Using general types where possible. Several more can go away once infinity gets figured out.
-
由 Sean Griffin 提交于
The `:timestamp` type for columns is unused. All database adapters treat them as the same database type. All code in `ActiveRecord` which changes its behavior based on the column's type acts the same in both cases. However, when the type is passed to code that checks for the `:datetime` type, but not `:timestamp` (such as XML serialization), the result is unexpected behavior. Existing schema definitions will continue to work, and the `timestamp` type is transparently aliased to `datetime`.
-
- 19 5月, 2014 3 次提交
-
-
由 Sean Griffin 提交于
The decision to wrap type registrations in a proc was made for two reasons. 1. Some cases need to make an additional decision based on the type (e.g. a `Decimal` with a 0 scale) 2. Aliased types are automatically updated if they type they point to is updated later. If a user or another adapter decides to change the object used for `decimal` columns, `numeric`, and `number` will automatically point to the new type, without having to track what types are aliased explicitly. Everything else here should be pretty straightforward. PostgreSQL ranges had to change slightly, since the `simplified_type` method is gone.
-
由 Yves Senn 提交于
-
- 15 5月, 2014 1 次提交
-
-
由 Rafael Mendonça França 提交于
-
- 14 5月, 2014 4 次提交
- 13 5月, 2014 1 次提交
-
-
由 Yves Senn 提交于
-
- 18 4月, 2014 1 次提交
-
-
由 Kris Selden 提交于
Optimize select_value, select_values, select_rows and dry up checking whether to exec with cache for Postgresql adapter Reduces creating unused objects, with the most dramatic reduction in select_values which used to map(&:first) an array of single element arrays.
-
- 11 4月, 2014 2 次提交
- 10 4月, 2014 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 04 4月, 2014 1 次提交
-
-
由 Yves Senn 提交于
There is no reason for the PG adapter to have a default limit of 255 on :string columns. See this snippet from the PG docs: Tip: There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead.
-