Thanks Army, for going through the wiki page and reviewing it.
I was thinking of using the character set of the schema where the statement is prepared. Your example demonstrates that from user point of view, this will be easier to understand and easier for us to document.
I will add your comment to the wiki page and address it at the end of the day along with other comments if nonone has objection to this approach.
On 4/3/07, Army <email@example.com> wrote:
Thank you very much for the wiki page, Mamta. It is indeed very helpful!
Mamta Satoor wrote:
> The character set of the schema the function is defined in. That keeps it
> least confusing and easier for the users to understand.
One question similar to Dan's, except mine is w.r.t:
> 8)JDBC parameters (ie. ?) where the type of the parameter is a character
> type will have the same collation as current schema's character set, based
> on 3) above.
Since a parameter maker does not have a "defined" schema, does "current schema"
mean the schema when the statement is prepared, or the schema when it is executed?
For example I can do the following in JDBC:
// Default schema ("APP").
PreparedStatement ps = conn.prepareStatement(
"select tablename, tabletype from sys.systables where tablename = ?");
ResultSet rs = ps.executeQuery();
System.out.println(" -=> " + rs.getString(1) + " - " + rs.getString(2));
// Change current schema.
s.execute("set schema sys");
rs = ps.executeQuery();
System.out.println(" -=> " + rs.getString(1) + " - " +
If we take "current schema" to mean the "schema when the statement is executed"
then the first statement will fail (comparison of different collations)) whereas
the second one will succeed.
If "current schema" means the "schema when the statement is prepared" then both
of the above statements would fail (because there's no CAST on the syscol). That
consistency would probably be a good thing (less confusing for users).