- 26 Nov, 2014 1 commit
-
-
David Zuelke authored
-
- 16 Nov, 2014 4 commits
-
-
David Zuelke authored
-
David Zuelke authored
-
David Zuelke authored
-
David Zuelke authored
tests to come
-
- 11 Nov, 2014 2 commits
-
-
Marco Pivetta authored
-
Marco Pivetta authored
-
- 10 Nov, 2014 1 commit
-
-
Alessandro Chitolina authored
Fixed undefined index notice when attempting to reconnect a MasterSlaveConnection after close has called
-
- 08 Nov, 2014 1 commit
-
-
Marco Pivetta authored
-
- 07 Nov, 2014 6 commits
-
-
jeroendedauw authored
-
jeroendedauw authored
-
Marco Pivetta authored
-
Marco Pivetta authored
-
Matteo Beccati authored
-
Matteo Beccati authored
-
- 05 Nov, 2014 4 commits
-
-
Steve Müller authored
-
Steve Müller authored
-
Steve Müller authored
-
Steve Müller authored
-
- 04 Nov, 2014 1 commit
-
-
Tobias Schultze authored
-
- 31 Oct, 2014 1 commit
-
-
Steve Müller authored
-
- 27 Oct, 2014 1 commit
-
-
Thomas Müller authored
-
- 26 Oct, 2014 1 commit
-
-
Steve Müller authored
-
- 23 Oct, 2014 8 commits
-
-
Steve Müller authored
-
Steve Müller authored
-
x42p authored
some format changes to trigger travis-cl once more again
-
x42p authored
I take the guess an use the information_schema. It makes it more clear and simple
-
x42p authored
correct table identifier
-
x42p authored
missing table identifier added
-
x42p authored
If the database have different schemes, with objects, that the actual logged in user has no rights, the existing statements will collect all objects (sequences and tables) and try to read them in later steps. This will throws exceptions. The reason for that is the fact, that both procedures getListSequencesList() and getListTablesSQL() will receive all known database objects from postgres catalogs. But the actual logged-in user, maby has no read permissions to object inside other scheme-owner. The additional parts inside both sql-statements will reduce the result to only objects that the user are able to see.
-
marius.klocke authored
-
- 22 Oct, 2014 1 commit
-
-
Steve Müller authored
-
- 21 Oct, 2014 1 commit
-
-
Steve Müller authored
-
- 20 Oct, 2014 4 commits
-
-
Steve Müller authored
-
Francisco Facioni authored
As seen here => http://technet.microsoft.com/en-us/library/cc626307(v=sql.105).aspx
-
Pavel Horal authored
TimeType resets date fields (i.e. unused DateTime object fields) to UNIX epoch (1970-01-01). This makes TIME field mapping stabe (i.e. same time will be always mapped to the same DateTime fields). See DDC-179 (similar issue with DateType). Fixes DBAL-993.
-
Steve Müller authored
-
- 19 Oct, 2014 1 commit
-
-
Marco Pivetta authored
-
- 17 Oct, 2014 2 commits
-
-
Steve Müller authored
-
Steve Müller authored
-