Open main menu

CDOT Wiki β

Changes

PostgreSQL Adapter Project - Resources

10 bytes added, 10:23, 24 November 2010
PostgreSQL Specifications
==PostgreSQL Specifications==
: * Installation: [http://www.postgresql.org/download/]: * [http://www.postgresql.org/docs/9.0/static/index.html Tutorial]: * [http://www.postgresql.org/docs/7.1/static/jdbc-ext.html postgre connection]
: * String literals and string functions in postgreSQL [http://www.postgresql.org/docs/current/static/functions-string.html]: * postgre gotchas [http://sql-info.de/postgresql/postgres-gotchas.html]: * Pattern Matching [http://pgsqld.active-venture.com/functions-matching.html: * Character set support -::The character set support in PostgreSQL allows you to store text in a variety of character sets (also called encodings), including single-byte character sets such as the ISO 8859 series and multiple-byte character sets such as EUC (Extended Unix Code), UTF-8, and Mule internal code. All supported character sets can be used transparently by clients, but a few are not supported for use within the server (that is, as a server-side encoding). The default character set is selected while initializing your PostgreSQL database cluster using initdb. It can be overridden when you create a database, so you can have multiple databases each with a different character set. An important restriction, however, is that each database's character set must be compatible with the database's LC_CTYPE (character classification) and LC_COLLATE (string sort order) locale settings. For C or POSIX locale, any character set is allowed, but for other locales there is only one character set that will work correctly. (On Windows, however, UTF-8 encoding can be used with any locale.) Note! Not all client APIs support all the listed character sets. For example, the PostgreSQL JDBC driver does not support MULE_INTERNAL, LATIN6, LATIN8, and LATIN10. [http://www.postgresql.org/docs/current/static/multibyte.html]: * BLOBs [http://www.postgresql.org/files/documentation/books/aw_pgsql/node96.html]:*some data type setups for postgreSQL driver @ [http://jdbc.postgresql.org/documentation/80/connect.html jdbc.postgresql.org ]: * Connection Pools And DataSources @ [http://www.postgresql.org/docs/7.3/static/jdbc-datasource.html PostgreSQL Documentation]*  ==MySQLSpecifications==: * [http://dev.mysql.com/doc/refman/5.1/en/sql-syntax.html Syntax]: * [http://dev.mysql.com/doc/refman/5.0/en/tutorial.html Tutorial]: * [http://www.mysql.com/downloads/connector/j/ Mysql Connector]: * '''IMP!''' Some optimization [http://www.petefreitag.com/item/613.cfm Hints]: * Retrieving AUTO_INCREMENT Column Values [http://dev.mysql.com/doc/refman/5.0/en/connector-j-usagenotes-basic.html#connector-j-usagenotes-last-insert-id]: * LikeEscape:[http://dev.mysql.com/doc/refman/5.0/en/string-comparison-functions.html#operator_like]:: Because MySQL uses C escape syntax in strings (for example, “\n” to represent a newline character), you must double any “\” that you use in LIKE strings. For example, to search for “\n”, specify it as “\\n”. To search for “\”, specify it as “\\\\”; this is because the backslashes are stripped once by the parser and again when the pattern match is made, leaving a single backslash to be matched against.::Exception: At the end of the pattern string, backslash can be specified as “\\”. At the end of the string, backslash stands for itself because there is nothing following to escape. Suppose that a table contains the following values:
<code>
mysql> SELECT filename FROM t1;
filename : C: | C:\ | C:\Programs | C:\Programs\
</code>
::To test for values that end with backslash, you can match the values using either of the following patterns:
<code>
mysql> SELECT filename, filename LIKE '%\\' FROM t1;
::filename | filename LIKE '%\\' |:: C: | 0 |:: C:\ | 1 |:: C:\Programs | 0 |:: C:\Programs\ | 1 |
mysql> SELECT filename, filename LIKE '%\\\\' FROM t1;</code> ( Will have the same result as above)
1
edit