ここにこれを書くのもちょっとぶりな気がしますが、A5:SQL Mk-2のベータ版を更新しました。
http://www.wind.sannet.ne.jp/m_matsu/developer/a5m2/index.html
主に、PostgreSQL向けの修正なのですが、PostgreSQLでは他のRDBMSと比べてちょっとだけ珍しい概念があります。それは検索パスという形でテーブル（あるいはその他のオブジェクト）へのアクセス時にスキーマを順に検索する機能です。
たとえば、PostgreSQLの検索パスはデフォルトでは「$user,public」となっています。これは、「接続ユーザーと同じスキーマがあればそこで該当テーブルを検索し、存在しなければpublicスキーマから検索する」という動作を示します。
A5:SQL Mk-2でSQL入力支援の仕様は、これまでは他のデータベースの仕様との兼ね合いから、「スキーマ名が省略されたテーブルは検索パスの1番目のスキーマに存在するものとみなす」としていました。これでは、publicスキーマに配置されたテーブルをうまく扱うことが出来ません。
このため beta18からは、検索パスを実際に検索してテーブルを探す仕様に変更しました。
PostgreSQLの場合、ユーザー名と同じ名前のスキーマを作らなかったら、テーブルがpublicスキーマに作成されてしまうので、結構該当するパターンもあると思われます。
例）shoppingユーザーで接続しているが、テーブルはpublicスキーマに有る
beta17まではスキーマを省略するとカラムの情報を列挙できない
beta18ではカラムの情報を列挙できる（型やコメントを含めて）
ちなみに、Oracleでも、PUBLICスキーマを検索しに行くように修正しましたが、OracleではあまりPUBLICスキーマにテーブルを作成することって無いですよね。
http://www.wind.sannet.ne.jp/m_matsu/developer/a5m2/index.html
主に、PostgreSQL向けの修正なのですが、PostgreSQLでは他のRDBMSと比べてちょっとだけ珍しい概念があります。それは検索パスという形でテーブル（あるいはその他のオブジェクト）へのアクセス時にスキーマを順に検索する機能です。
たとえば、PostgreSQLの検索パスはデフォルトでは「$user,public」となっています。これは、「接続ユーザーと同じスキーマがあればそこで該当テーブルを検索し、存在しなければpublicスキーマから検索する」という動作を示します。
A5:SQL Mk-2でSQL入力支援の仕様は、これまでは他のデータベースの仕様との兼ね合いから、「スキーマ名が省略されたテーブルは検索パスの1番目のスキーマに存在するものとみなす」としていました。これでは、publicスキーマに配置されたテーブルをうまく扱うことが出来ません。
このため beta18からは、検索パスを実際に検索してテーブルを探す仕様に変更しました。
PostgreSQLの場合、ユーザー名と同じ名前のスキーマを作らなかったら、テーブルがpublicスキーマに作成されてしまうので、結構該当するパターンもあると思われます。
例）shoppingユーザーで接続しているが、テーブルはpublicスキーマに有る
beta17まではスキーマを省略するとカラムの情報を列挙できない
beta18ではカラムの情報を列挙できる（型やコメントを含めて）
ちなみに、Oracleでも、PUBLICスキーマを検索しに行くように修正しましたが、OracleではあまりPUBLICスキーマにテーブルを作成することって無いですよね。
