Yeshql cannot handle :: cast in postgresql

[noxecane]

Expected Behaviour

[yesh|
  -- name: getMytable :: ()
  select *, now() - '1 hour ago'::interval from mytable;
|]

should generate

select *, now() - '1 hour ago'::interval from mytable;

Actual Behaviour

select *, now() - '1 hour ago'

My guess is yeshql is detecting :: in queries. I thought it would only use those in comments(--) For now I am using cast directly. I would have liked to send a patch but I know close to nothing of neither template-haskell not QuasiQuoting

[tdammers]

You are right, this doesn't work - :: inside queries is yeshql magic, interpreted as a type annotation, as an alternative to annotating parameters in comments. That is, instead of this:

-- name: getMytable :: ()
-- :id :: Int
SELECT * FROM mytable WHERE id = :id

...you could also write:

-- name: getMytable :: ()
SELECT * FROM mytable WHERE id = :id :: Int

Both forms are equivalent, however, the first form allows you to order parameters independently from the order in which they are found inside the query.

I'm not entirely sure how to fix this clash with PostgreSQL syntax; possibilities would include:

• Removing this feature, allowing type annotations only in comments. This is the most thorough solution, but sacrifices a potentially useful feature.
• Add a switch somewhere to opt into or out of this feature. This would complicate the API a little, but could be worth it.
• Add an option somewhere to change the syntax for type annotations. This would complicate the API a little more though.
• Make the parser more picky - we only really want to accept such type annotations after named parameters, e.g. :id :: Int, but not after anything else, so 'foo' :: text should not parse as a type annotation, but be left alone. This of course still leaves us with queries where you want to have a parameter as one type, but then have PostgreSQL cast it to another, which can be worked around, but it'd still be a somewhat surprising wart.

[noxecane]

I think the second option balances things. I would have preferred the first one, but since this is a postgresql only syntax it'll be better to use an opt-out switch. The other two just bring complexity that'll be too much for a simple library