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
> 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
I found bugs in the analyze functions:
nspname and relname are not initialized to NULL.
This causes failure if the corresponding option is not set
on the foreign table.
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"
ERROR: value too long for type character varying(3)
It might me nice for finding problems if the message were
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
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2012-04-03 13:34:41|
|Subject: Re: patch for parallel pg_dump|
|Previous:||From: Andrew Dunstan||Date: 2012-04-03 13:26:52|
|Subject: parallel pg_dump|