Dose JSqlParser have plan to support Hive?

[kiddyu]

Dose JSqlParser have plan to support Hive?

[manticore-projects]

Greetings.

While I am only a contributor and can't speak on behalf of JSQLParser, I think we would be able to support HIVE fully when sponsored by an interested party.

Alternatively, Source Contributions and PR's would be welcome.

[wumpz]

@kiddyu If I remember right, there already were Hive specific requests and implementations. JSqlParser is feature driven and not DBMS driven. So should not request for a specific database system but for specific syntactic constructs. So which special SQLs do you need to parse?

[manticore-projects]

@wumpz: Since these questions come up quite frequently, I have checked out HIVE. Its not a SQL DB, but rather a "SQL alike" compatibility layer around Apache Hadoop.

While it resembles most ideas around SQL, it is as far from the SQL standard as JavaScript is from Java.
To me, it looks like it will need more than just amending a few productions in the Grammar and it would either be a "full HIVE support" thing or "No HIVE support" at all (except the few statements which are SQL compliant).

Maybe a template based JHiveParser on top of the JSQLParser framework...

[wumpz]

@manticore-projects I am not familiar with the HIVE QL, so the standard workflow fits in, which means that every feature request is evaluated if it could / should be included. A template at least at grammar level seems to be difficult, since still in pure javacc there are no "import" statements and alternatives that have "import" are ruled out for specific reasons.

[manticore-projects]

so the standard workflow fits in, which means that every feature request is evaluated if it could / should be included.

Greetings @wumpz.

Your assessment is correct, although (after looking a bit into the Hive SQL alike syntax), my concerns are:

1. We would need to add quite of a few productions not compatible/useful for any other RDBMS.
   Look at the ALTER TABLE ... ADD COLUMN... example: Hive implements the same semantic, just different syntax and so would likely need its own production for it. No idea, why they did that.

2. We would introduce a lot more LOOKAHEADs, while we both observe and agree, that we need to avoid LOOKAHEAD as much as possible.

In my own opinion we would like to look into a more modular, object oriented design which:

a) uses Grammar Templates
b) from which a specific Grammar was derived for "Standard SQL and Friends", but also more obscure SQL dialects far away from standards (MySQL, Hive and other suspects)
c) generate an individual parser for each

Its just an idea, thinking out loud. It would be a lot of work and effort with no benefit for myself (because we do stick to Standard SQL).

[manticore-projects]

Impression, beside KEYWORD related issues, "Hive support" is now the second often mentioned concern.