Postgresql - issue with INSERT INTO statement - sql

Question

I have the following SQL:
drop table if exists core.fact_request_tickets;
create table core.fact_request_tickets (
id serial4 primary key,
ticket_no text not null,
title text not null,
sender_id int4 not null,
request text not null,
status_id int4 not null,
is_latest boolean null,
group_id int4 not null,
size_id int4 not null,
business_partner_team_project_id int4 not null,
"log" text not null,
rating_met_sla_id int4 not null,
rating_communicated_id int4 not null,
rating_timely_id int4 not null,
rating_self_sufficient_id int4 not null,
rating_complete_and_accurate_id int4 not null,
log_date timestamptz not null,
etl_batch_id int4 not null
);
with finalTable as (
select rts.ticket_no
, rts.title
, rts.sender_id
, rts.request
, rts.status_id
, (case when ls.last_log_date is null then false else true end) as is_latest
, rts.group_id
, rts.size_id
, rts.business_partner_team_project_id
, rts."log"
, rts.rating_met_sla_id
, rts.rating_communicated_id
, rts.rating_timely_id
, rts.rating_self_sufficient_id
, rts.rating_complete_and_accurate_id
, rts.log_date
, rts.etl_batch_id
from requestTickets rts
left join lastStatus ls on rts.log_date = ls.last_log_date
)
insert into core.fact_request_tickets
( ticket_no
, title
, sender_id
, request
, status_id
, is_latest
, group_id
, size_id
, business_partner_team_project_id
, "log"
, rating_met_sla_id
, rating_communicated_id
, rating_timely_id
, rating_self_sufficient_id
, rating_complete_and_accurate_id
, log_date
, etl_batch_id
)
select ticket_no
, title
, sender_id
, request
, status_id
, is_latest
, group_id
, size_id
, business_partner_team_project_id
, "log"
, rating_met_sla_id
, rating_communicated_id
, rating_timely_id
, rating_self_sufficient_id
, rating_complete_and_accurate_id
, log_date
, etl_batch_id
from finalTable
commit;
When I execute the following SQL:
select ticket_no
, title
, sender_id
, request
, status_id
, is_latest
, group_id
, size_id
, business_partner_team_project_id
, "log"
, rating_met_sla_id
, rating_communicated_id
, rating_timely_id
, rating_self_sufficient_id
, rating_complete_and_accurate_id
, log_date
, etl_batch_id
from finalTable
It returns data that I am expecting - specifically, there are records that have 'true' for the is_latest column. However, when I execute the entire script, and then I query the core.fact_request_tickets table, all the values for the is_latest column show up as 'false'. It seems the INSERT INTO statement is causing the data inserted into the core.fact_request_tickets table to show up incorrectly (there should be some records with a true value for is_latest, but instead all values return as false); but when I run the query against finalTable separately, it returns the data I am expecting.
I'm not sure why this is happening - any ideas?

Answer 1

It's got to be a syntax error in the script itself and unrelated to the "WITH AS" clause.
Semicolons are needed after the entire INSERT statement and before COMMIT;
COMMIT may not be supported in the batch environment you have (executing as OWNER context), rolling back any pending changes (so next select is looking at the old data).
I recommend sticking to a plain INSERT - SELECT statement (and testing that separately):
insert into core.fact_request_tickets
( ticket_no
, title
, sender_id
, request
, status_id
, is_latest
, group_id
, size_id
, business_partner_team_project_id
, "log"
, rating_met_sla_id
, rating_communicated_id
, rating_timely_id
, rating_self_sufficient_id
, rating_complete_and_accurate_id
, log_date
, etl_batch_id
) select rts.ticket_no
, rts.title
, rts.sender_id
, rts.request
, rts.status_id
, (case when ls.last_log_date is null then false else true end) as is_latest
, rts.group_id
, rts.size_id
, rts.business_partner_team_project_id
, rts."log"
, rts.rating_met_sla_id
, rts.rating_communicated_id
, rts.rating_timely_id
, rts.rating_self_sufficient_id
, rts.rating_complete_and_accurate_id
, rts.log_date
, rts.etl_batch_id
from requestTickets rts
left outer join lastStatus ls
on rts.log_date = ls.last_log_date;
Also, if this is a one-time query, consider using temporary tables. Which saves you overhead of logging and saving results permanently. A permission to create them may need to be granted to the batch account.