Closed pcorbel closed 4 years ago
@pcorbel does target-redshift
/target-postgres
create TIMESTAMP WITHOUT TIME ZONE
columns somewhere?
Currently, the thinking is that the only supported tables are those that the target
created.
@AlexanderMann does target-redshift/target-postgres create TIMESTAMP WITHOUT TIME ZONE columns somewhere? --> No
I agree that only supported tables are those that the datamill-co/target-redshift
created.
However, as of today, we need the totality of the tables in the schema to be created by datamill-co/target-redshift
.
We can't have:
But only:
@pcorbel do you know whether you're getting these errors on just running the target
, or is it when a stream you're processing tries to persist to a table created by some other means?
ie, is it:
FOO
tries to persist to remote table foo
a table created and maintained by target-redshift
bar
, exists in the remote schema which has been created by another processFOO
tries to persist to remote table foo
which exists in the remote schema which has been created by another processI ask, because I think the guidance has been that target
s should probably be run in their own schemas and if they happen to work alongside other processes, that's great, but not a given. For target-redshift
specifically, we've turned down trying to support tables not created and maintained by target-redshift
.
The reason for this is that the stores a tonne of metadata into the remote table's COMMENT
and has to use that for most operations.
@AlexanderMann It is the 1 case you mentioned. My usecase is that I would like to migrate some tables from Stitch to in-house extraction. To be able to do it in a transparent and smooth way, I would like my end users to use the same table name, in the the same schema name. It is just the extraction that would be different.
Fascinating. So @pcorbel to be clear, you are not looking to mix and match maintenance of tables between target-redshift
and something else, but rather are looking to simply use it inside a schema which has other things in it?
If yes, I think we should identify where the code is blowing up by pulling in other stuffs first, as I can easily see this becoming a game of whack-a-mole with types etc.
Amazon Redshift has a data type "timestamp without time zone" which isn't supported by the target yet (only "timestamp with time zone" is supported via target-postgres)
Source: https://docs.aws.amazon.com/redshift/latest/dg/c_Supported_data_types.html
So when target-redshift scan the destination schema, the following error occurs: