On 04/05/2014 05:15 PM, pg_gg@mailinator.com wrote:
> I don't think the problem is only with the OGG. My understanding is that
> OGG polls the destination metadata first and then describes and prepares
> the parameters and the SQL statement based on the metadata. Either OGG
> interprets what it receives from PG differently than other tools, or the
> driver behaves differently for OGG, and that's what we are trying to
> understand based on the code. Just don't know where to look.
I would say, start with Oracle, it is their product. I am going to
assume support is part of the package. or am I wrong?
There is some evidence it does treat things differently:
http://docs.oracle.com/cd/E35209_01/doc.1121/e29642.pdf
"timestamptz data type
PostgreSQL
timestamp with timezone
column type is recognized as
SQL_VARCHAR
and therefore
Oracle GoldenGate writes the data in the native
format of the source
database, rather than
normalizing it to its PostgreSQL form. As a
result, some replicated timestamp data might
not be compatible with Oracle GoldenGate column-conversion functions and
FILTER
clauses."
>
> Also the DataDirect ODBC only handles timestamps when it's defined
> without a percision in which case the metadata query returns -1 for the
> field lenght. If precision is defined, even if it's 6 then it fails with
> the error mentioned in the link below and we would need to set the
> WorkArounds2=2. But that doesn't solve the problem because then it nags
> about data overflowing. So the only way to make the Data Driect drive to
> work is to not define the precision, but as I mentioned before, that
> driver doesn't handle Unicode null character, so we can't really use it.
>
--
Adrian Klaver
adrian.klaver@aklaver.com
