Re: pgsql_fdw, FDW for PostgreSQL server
Albe Laurenz <laurenz.albe@wien.gv.at>
From: "Albe Laurenz" <laurenz.albe@wien.gv.at>
To: "Shigeru HANADA *EXTERN*" <shigeru.hanada@gmail.com>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>, "Kevin Grittner" <Kevin.Grittner@wicourts.gov>, "Robert Haas" <robertmhaas@gmail.com>, "PostgreSQL-development" <pgsql-hackers@postgresql.org>, "Kohei KaiGai" <kaigai@kaigai.gr.jp>, "Martijn van Oosterhout" <kleptog@svana.org>, "Etsuro Fujita" <fujita.etsuro@lab.ntt.co.jp>, "Hitoshi Harada" <umi.tanuki@gmail.com>
Date: 2012-04-03T13:31:46Z
Lists: pgsql-hackers
Shigeru HANADA wrote: > Attached are latest version of pgsql_fdw patches. Note that > pgsql_fdw_analyze.patch is only for test the effect of local statistics. > Please apply patches in the order below: > > (1) pgsql_fdw_v18.patch > (2) pgsql_fdw_pushdown_v11.patch > (3) pgsql_fdw_analyze.patch (if you want to try local stats) Since Kohei KaiGai doesn't post a review, I'll have a go. The patch applies and compiles fine without warnings and passes regression tests. I found bugs in the analyze functions: In pgsql_fdw_analyze: nspname and relname are not initialized to NULL. This causes failure if the corresponding option is not set on the foreign table. In store_remote_stats: atttypmod is initialized to 0 and never changed. This causes the following error for columns of type "interval": ERROR: unrecognized interval typmod: 0 During a foreign scan, type input functions are used to convert the text representation of values. If a foreign table is misconfigured, you can get error messages from these functions, like: ERROR: invalid input syntax for type double precision: "etwas" or ERROR: value too long for type character varying(3) It might me nice for finding problems if the message were something like: ERROR: cannot convert data in foreign scan of "tablename", column "col" in row 42 DETAIL: ERROR: value too long for type character varying(3) As stated previously, I don't think that using local stats on foreign tables is a win. The other patches work fine for me, and I'd be happy if that could go into 9.2. Once the two bugs above are fixed, should I mark it "ready for committer"? Yours, Laurenz Albe