now() vs. 'now'::timestamptz

[johto]

I was browsing the source code for fun and happened to see this:

    sqlInsertJob = `
INSERT INTO que_jobs
(queue, priority, run_at, job_class, args)
VALUES
(coalesce($1::text, ''::text), coalesce($2::smallint, 100::smallint), coalesce($3::timestamptz, 'now'::timestamptz), $4::text, coalesce($5::json, '[]'::json))
`

This is almost certainly wrong, since the 'now'::timestamptz is materialized when the statement is prepared. A small test case here.

The fix is to use now() instead.

.. though now I see that the "que_insert_job" prepared statement isn't actually used. Perhaps that was unintentional? In any case, the SQL is flawed regardless of whether it's actually being prepared or not.

[bgentry]

Thanks @johto. Wasn't watching this repo until today but I'll look into this

[bgentry]

Thanks @johto, I think I've resolved this now. I also opened que-rb/que#74 to resolve this problem in that project.

[bgentry]

Oh, also, I missed using the que_insert_job prepared statement before when I began relying on the prepared statements, but we're using that statement now. If you have any ideas on how to avoid exposing PrepareStatements() in the first place, I'd be interested :) Unfortunately they have to be prepared once per conn and I don't see a way to do that lazily as the Ruby version does (since I don't think my package can distinguish between conns in a pool).