Or possibly how to retire it and then re-do similarity joins using the
join infrastructure ideas discussed a year or so ago, perhaps. (We
should think about whether or not the time it would take to do SQL+++
might be better used to not use that approach anymore - it was an
interesting experiment at the time it was done, but it's probably worth
having a revisiting discussion 5 years later - and also whether the
algorithm as it was invented is still the preferred one to support -
though the required SQL+++ query would surely be an interesting SQL++
optimizer test... :-))
On 9/7/17 10:21 PM, Chen Li wrote:
Let's discuss how to move AQL+ to SQL++ after Taewoo comes back.
On Thu, Sep 7, 2017 at 12:10 PM, Taewoo Kim <[email protected]> wrote:
For similarity join, we use AQL+ that is based on AQL. I think deprecating
(not removing) AQL is OK. Ultimately, AQL+ should be converted to SQL++ :-)
Best,
Taewoo
On Thu, Sep 7, 2017 at 9:04 PM, Steven Jacobs <[email protected]> wrote:
I’ll give the BADest +1 I can :)
Steven
On Thu, Sep 7, 2017 at 8:50 PM Gerald Sangudi <[email protected]> wrote:
:-)
On Sep 7, 2017 11:44 AM, "Michael Carey" <[email protected]> wrote:
As AsterixDB evolves, and additional features are added - e.g.,
DISTINCT
aggregate support, or properly implemented query-bodied functions,
supporting two query languages is hugely expensive: Updating two
grammars,
parsers, rules, tests, ... IMO it is time to let go of AQL as an
externally
supported interface to AsterixDB and only have SQL++ going forward. I
think "everyone" has migrated - and if not we should force that
migration.
(Cloudberry is on SQL++ nowadays, BAD is on SQL++ nowadays, ...) Any
objections? If not, I think we should make this decision officially
and
stop putting energy into carrying the AQL legacy around with us.
Thoughts?
