Hey Dmitry, I had seen your comments + previous posts on the forums In that issue I also commented, hoping that the CrateDB folks would break apart their implementation a bit
Initially I also tried to do a port based on their code, but found that it was very tied in with many dependency packages like ElasticSearch (why?) and a lot of domain-specific types that only have meaning inside of CrateDB, like their internal representation of rels. Their implementation is much better/more thorough -- on the other hand, mine has zero deps (besides Netty) I would consider my project a prototype/proof-of-concept phase, just wanted to share it in case others were interested =) At the moment I am trying to emulate pg_catalog schema using calcite and it > is painful. > Yes this is huge, and the most important thing for Postgres compatibility Possibly you could have a SchemaPlus called "pg_catalog", with identical columns, and have a listener that watches for schemas being registered/un-registered Any time a Calcite schema is added or removed, the corresponding info should be programmatically added to the "pg_catalog" SchemaPlus void handleSchemaAdded(SchemaPlus rootSchema, SchemaPlus newSchema) void handleSchemaRemoved(SchemaPlus rootSchema, SchemaPlus removedSchema) For Hasura I can "cheat" a little bit by intercepting ver-batim SQL queries that we use for introspection and treating them as opaque values + running a function and returning the right data for it. On Sun, May 8, 2022 at 2:08 AM Dmitry Sysolyatin <[email protected]> wrote: > Cool! > > I am also working on it in our company, we implemented postgres wire > protocol based on cratedb code and integrated it with calcite. CrateDB has > a really good implementation of Postgres wire protocol and I tried to push > them to make a separate library > https://github.com/crate/crate/issues/12002 > > At the moment I am trying to emulate pg_catalog schema using calcite and it > is painful. Calcite can't handle many things yet. For example, psql sends > the following sql on the `\dt+` command: > > SELECT > c.relchecks, c.relkind, c.relhasindex, c.relhasrules, c.relhastriggers, > c.relrowsecurity, c.relforcerowsecurity, c.relhasoids, c.relispartition, > pg_catalog.array_to_string(c.reloptions || array(select 'toast.' || x from > pg_catalog.unnest(tc.reloptions) x), ', '), c.reltablespace, CASE WHEN > c.reloftype = 0 THEN '' ELSE > c.reloftype::pg_catalog.regtype::pg_catalog.text END, c.relpersistence, > c.relreplident > FROM pg_catalog.pg_class c > LEFT JOIN pg_catalog.pg_class tc ON (c.reltoastrelid = tc.oid) > WHERE c.oid = '1' > > 4-5 tasks were created in calcite JIRA only for this query. There are many > others queries that should work ) > > Maybe when we will finish emulating pg_catalog we will open-source the code > of the integration calcite with Postgres wire protocol. > > On Sun, May 8, 2022 at 12:21 AM Gavin Ray <[email protected]> wrote: > > > A while ago I saw a mention on the mailing list of someone interested in > > making > > Calcite speak Postgres' wire protocol, so all existing tools/client > > libraries > > could interface with it. > > > > I couldn't find anything on the internet for this -- either for > Calcite,or > > surprisingly even a JVM toolkit for building wire protocol services > (empty > > interfaces) > > > > Spent the last few weekends hacking on this, just today got a prototype > to > > a > > point where I can query Calcite from psql > > > > Thought I'd share here in case others are interested, here's a video demo > > and repo: > > > > https://twitter.com/GavinRayDev/status/1523048629883514881 > > https://github.com/GavinRay97/PgProtoKt > > >
