Yes that sounds like it. I'm looking at this patch for the corresponding issue:
https://github.com/apache/drill/pull/698/files#diff-6b274c93088e03d7ee1d7d266fcf4ac8R133 And I don't understand why the issue says that this patch only handles the "show schema" case, but it looks like it handles any case that isn't SELECT. That said, for it to be completely correct it should also handle UPDATEs, right? I'm admittedly unclear on what the purpose of the "LIMIT 0" is... I'll try applying this patch to see if it fixes my issue. Thanks, Wes On Mon, Apr 24, 2017 at 5:49 PM, Zelaine Fong <[email protected]> wrote: > I suspect you’ve hit https://issues.apache.org/jira/browse/DRILL-5136. > See the comment trail which mentions the problem with CTAS. > > -- Zelaine > > On 4/24/17, 2:45 PM, "Kunal Khatua" <[email protected]> wrote: > > I'm not sure if you can do a > > select * from (CTAS ..) > > The output of CTAS really is only a metric of the rows that got > written by the various fragments. Are you able to run the query in SQLLine? > > The parse error does a pretty good job of pointing out where the query > appears to have broken the parser's semantics. So it is possible that you > need some escape characters to handle the query, without which, Python > might be altering the query. > > > Kunal > > ________________________________ > From: Wesley Chow <[email protected]> > Sent: Monday, April 24, 2017 2:33:14 PM > To: [email protected] > Subject: JDBC SQL parse error on CTAS > > I'm seeing a funny issue where issuing SELECT statements through the > JDBC > driver is fine, but when I prepend them with CREATE TABLE AS, I start > getting parse errors. If I copy+paste the query string into sqlline the > CTAS works. When the thing breaks, it gives me an exception with > message > like: > > SQL Query SELECT * FROM (CREATE TABLE foo ... ) LIMIT 0 > > And complains about a parse error at the CREATE TABLE step. Now this is > weird to me, because it seems like the driver is automatically > wrapping the > CTAS with a "SELECT * FROM ... LIMIT 0"? > > An additional complication is that this isn't straight up JDBC. This is > Python calling out to the JDBC driver, so admittedly I might be > throwing a > wrench in there somewhere. But it doesn't make sense to me that either > the > Python layer or JDBC would modify the query in that way. I've checked > the > Python wrapper source and there I couldn't find anything to indicate it > might be changing the query. I also briefly sifted through the JDBC > code > and couldn't find anything as well. > > Any clues as to what might be going on? > > Wes > > >
