honeysql

markaddleman 2024-03-22T15:35:07.177709Z

Single quote is treated inconsistently:

{:create-table-as [(keyword "'`a-b.b-c.c-d`")]
 :select          [:*]
 :from            [(keyword "'`a-b.b-c.c-d`")]}
produces
CREATE TABLE \"'`a_b\".b_c.\"c_d`\" AS SELECT * FROM `a-b.b-c.c-d
` When I would expect
CREATE TABLE `a-b.b-c.c-d` AS SELECT * FROM `a-b.b-c.c-d
` This is important in BigQuery where backticks are somewhat common

markaddleman 2024-03-29T16:47:08.206029Z

I don’t know MySQL but in BQ, the backtick is quoting for table names and other database references. It is required when the name includes special characters like a dash.

markaddleman 2024-03-29T16:49:21.594349Z

The NRQL dialect looks like it produces the right result for BQ. I can play around with it to see how well it fits more broadly

seancorfield 2024-03-29T16:52:00.588949Z

The main issue is that in HoneySQL foo.bar is split and quoted as "foo"."bar" or foo.`bar` etc but NRQL doesn't have table/column designations like that so foo.bar is just a column name. I thought BQ had table/column designations like other DBs so I'm a bit surprised that you want a-b.b-c rather than a-b.`b-c`?

markaddleman 2024-03-29T16:53:39.449519Z

I see. In BQ, dot serves as a namespace separator for fully qualified names. In BQ, a fully qualified name is project-name.`dataset`.`name`

markaddleman 2024-03-29T16:54:47.524239Z

fwiw, I don’t believe [:. :project :dataset :name] works within :create-table-asbecause honey doesn’t treat the name as a sql expression and, thus, the :. function is not evaluated

seancorfield 2024-03-29T18:11:18.398489Z

Yeah, I try not to support full expressions where normally only entities are needed... it's a difficult balancing act because different DBs have different rules about entity names and expressions and so on. I may revamp some of the entity name handling at some point to try to remove some of the context dependent logic -- which should make it easier to do "weird" stuff for certain databases... but which will also make it "easier" to accidentally generate bad SQL 😐

markaddleman 2024-03-29T18:11:50.897889Z

With great power… 🙂

markaddleman 2024-03-29T18:14:01.495609Z

One possible solution is to support literals (`[:raw ..]`?) for entities instead of full expression support (I haven’t looked into the code so I don’t know if this proposal simplifies the problem)

markaddleman 2024-03-29T18:14:24.765569Z

It’s really just that I need an escape hatch every once in a while

seancorfield 2024-03-29T18:17:15.445119Z

[:raw ..] and [:. ..] are essentially the same "level" in terms of formatting so it's either "just entities" or "full expressions" right now. I'd need to plumb in some "in-between" option and retrofit entity handling (which has its own special cases) on top of that...

seancorfield 2024-03-29T18:17:30.670449Z

I'll leave that issue open while I think about it...

markaddleman 2024-03-29T18:19:48.720849Z

fwiw, my opinion is for full expression support rather than invent a new “level” that only works for entities. It doesn’t add to the cognitive load of the library and it gives me the option of registering expression functions that are appropriate for entities. In effect, these entity expression functions would act as macros.

markaddleman 2024-03-29T18:20:00.888289Z

Thanks for thinking about this

seancorfield 2024-03-29T18:22:56.798299Z

I would certainly like to remove several of the current special cases around this... but I don't want to break anyone's existing code...

markaddleman 2024-03-29T18:23:17.087209Z

Gotcha

seancorfield 2024-03-29T05:31:31.127889Z

@markaddleman Is the backtick meant to represent the stropping (quoting) of identifiers in BigQuery? i.e., like MySQL?

seancorfield 2024-03-29T05:39:10.453319Z

I ask because NRQL has a similar backtick quoting strategy that doesn't split keywords on dots:

(->
   {:create-table-as [:a-b.b-c.c-d]
    :select          [:*]
    :from            [:a-b.b-c.c-d]}
   (sql/format {:dialect :nrql}))
produces
["CREATE TABLE `a-b.b-c.c-d` AS SELECT * FROM `a-b.b-c.c-d`"]

seancorfield 2024-03-29T05:40:11.624629Z

(the :' syntax has a very specific meaning in HoneySQL and it is context dependent so, yes, of course it is going to behave differently in different contexts)

seancorfield 2024-03-22T19:23:29.468489Z

https://github.com/seancorfield/honeysql/issues/526