【问题标题】:Redshift cannot insert, timestamp column is of type stringRedshift 无法插入,时间戳列是字符串类型
【发布时间】:2020-12-18 19:06:14
【问题描述】:

我在 redshift 中有两个表,它们是彼此的精确副本(scans、scans_staging),一个是临时表,另一个是主表。他们有以下 DDL:

CREATE TABLE scans_staging (
    id text,
    imb text,
    scandatetime timestamp without time zone,
    scaneventcode text,
    status text,
    anticipateddeliverydate timestamp without time zone,
    scanfacilityname text,
    scanfacilitystate text,
    scanfacilitycity text,
    scanfacilityzip text
);

我正在尝试运行查询以将数据从暂存表更新到扫描表,如下所示:

insert into scans
select scans_staging.*
from scans
right join scans_staging on scans.id = scans_staging.id
where scans.id is null

但是我得到了错误:Invalid operation: column "scandatetime" is of type timestamp without time zone but expression is of type character varying

但是当我查看两个表中的数据时,时间戳的格式完全相同,例如2020-11-23 16:17:02。他们在yyyy-MM-dd HH:mm:ss。我在这里犯了什么菜鸟错误?

编辑:这是下表 def 查询的结果:

select "column", type, encoding, distkey, sortkey, "notnull" 
from pg_table_def
where tablename = 'scans' 

两个表

Scans:

|column                 |type                       |encoding|distkey|sortkey  |notnull|
----------------------------------------------------------------------------------------
|id                     |character varying(256)     |lzo     |false  |0        |false  |
|imb                    |character varying(256)     |lzo     |false  |0        |false  |
|scandatetime           |timestamp without time zone|az64    |false  |0        |false  |
|scaneventcode          |character varying(256)     |lzo     |false  |0        |false  |
|status                 |character varying(256)     |lzo     |false  |0        |false  |
|anticipateddeliverydate|timestamp without time zone|az64    |false  |0        |false  |
|scanfacilityname       |character varying(256)     |lzo     |false  |0        |false  |
|scanfacilitystate      |character varying(256)     |lzo     |false  |0        |false  |
|scanfacilitycity       |character varying(256)     |lzo     |false  |0        |false  |
|scanfacilityzip        |character varying(256)     |lzo     |false  |0        |false  |

Scans_staging:

|column                 |type                       |encoding|distkey|sortkey  |notnull|
----------------------------------------------------------------------------------------
|id                     |character varying(256)     |lzo     |false  |0        |false  |
|imb                    |character varying(256)     |lzo     |false  |0        |false  |
|scandatetime           |timestamp without time zone|az64    |false  |0        |false  |
|scaneventcode          |character varying(256)     |lzo     |false  |0        |false  |
|status                 |character varying(256)     |lzo     |false  |0        |false  |
|anticipateddeliverydate|timestamp without time zone|az64    |false  |0        |false  |
|scanfacilityname       |character varying(256)     |lzo     |false  |0        |false  |
|scanfacilitystate      |character varying(256)     |lzo     |false  |0        |false  |
|scanfacilitycity       |character varying(256)     |lzo     |false  |0        |false  |
|scanfacilityzip        |character varying(256)     |lzo     |false  |0        |false  |

【问题讨论】:

  • 可能不是问题,但对于插入和选择,您应该指定列而不使用 select *(或将列列表留空以插入表中)

标签: sql datetime amazon-redshift sql-insert


【解决方案1】:

如果两个表的结构完全相同,则不会出现该错误。

我将首先枚举insertselect 子句中的列,以避免列未出现在两个表中的相同位置的潜在问题:

insert into scans (
       id, imb, scandatetime, scaneventcode, status, anticipateddeliverydate, scanfacilityname, scanfacilitystate, scanfacilitycity, scanfacilityzip
)
select id, imb, scandatetime, scaneventcode, status, anticipateddeliverydate, scanfacilityname, scanfacilitystate, scanfacilitycity, scanfacilityzip
from scans_staging ss
where not exists  (select 1 from scans s where s.id = ss.id)

如果您仍然收到类型不匹配错误,这表明您的列具有不同的数据类型。如果是这样,您需要在 select 子句中设置额外的强制转换。

【讨论】:

  • 嗨,你能看看我刚刚对表定义进行的更新,看看是否重要?
  • @DBA108642:好的,看起来数据类型确实对齐了。但是,这并没有显示表中列的顺序。当您尝试我在回答中提供的查询时会发生什么?
  • 我现在正在运行它,它还没有出错,所以我认为这是一个好兆头。它可能已经成功了
  • 确认您的查询有效。谢谢!
猜你喜欢
  • 1970-01-01
  • 2021-06-18
  • 2021-11-26
  • 1970-01-01
  • 2020-02-17
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-07-23
相关资源
最近更新 更多