aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/connection_adapters/postgresql/oid/specialized_string.rb
Commit message (Collapse)AuthorAgeFilesLines
* rm `Type#text?`Sean Griffin2015-02-071-4/+0
| | | | | | | | | | | | | | | | This predicate was only to figure out if it's safe to do case insensitive comparison, which is only a problem on PG. Turns out, PG can just tell us whether we are able to do it or not. If the query turns out to be a problem, let's just replace that method with checking the SQL type for `text` or `character`. I'd rather not burden the type objects with adapter specific knowledge. The *real* solution, is to deprecate this behavior entirely. The only reason we need it is because the `:case_sensitive` option for `validates_uniqueness_of` is documented as "this option is ignored for non-strings". It makes no sense for us to do that. If the type can't be compared in a case insensitive way, the user shouldn't tell us to do case insensitive comparison.
* Correctly ignore `case_sensitive` for UUID uniqueness validationSean Griffin2014-12-261-0/+4
| | | | | | | | I think we should deprecate this behavior and just error if you tell us to do a case insensitive comparison for types which are not case sensitive. Partially reverts 35592307 Fixes #18195
* Remove the `text?` predicate from the type objectsSean Griffin2014-07-061-4/+0
| | | | | | | This was only used for uniqueness validations. The first usage was in conjunction with `limit`. Types which cast to string, but are not considered text cannot have a limit. The second case was only with an explicit `:case_sensitive => true` option given by the user.
* add missing `:nodoc:` for recent refactorings. [ci skip]Yves Senn2014-06-241-1/+1
| | | | | | | | | | Adding `# :nodoc:` to the parent `class` / `module` is not going to ignore nested classes or modules. There is a modifier `# :nodoc: all` but sadly the containing class or module will continue to be in the docs. /cc @sgrif
* Move PG OID types to their own filesSean Griffin2014-05-211-0/+19
As we promote these classes to first class concepts, these classes are starting to gain enough behavior to warrant being moved into their own files. Many of them will become quite large as we move additional behavior to the type objects.