a way to retreive all public tables

[maestro-1]

A way to retrieve all the public tables in databases #751 by creating a get_tables function in both the Postgres and MySQL dialect. In the absence of the reflection and inspection abstraction of sqlalchemy in gino, this is the least possible way of retrieving some form of metadata from the database without having to write personalized SQL queries in your project. It works the same as any function in the dialect module of the gino connection or engine.

conn = await engine.acquire()
return await engine.dialect.get_table_names(conn)

[wwwjfy]

If we're to have the same functions as sqlalchemy, I'd prefer having same logic/behavior as sqlalchemy. https://github.com/sqlalchemy/sqlalchemy/blob/master/lib/sqlalchemy/dialects/mysql/base.py#L2939 and https://github.com/sqlalchemy/sqlalchemy/blob/master/lib/sqlalchemy/dialects/postgresql/base.py#L3286 are a bit different than the ones in the diff.

[maestro-1]

My PR reflects acts as such as well. However, I am working on a way to have gino have full access to sqlalchemy functions without throwing the error of #751. This PR however reflects the bare minimum for getting back some metadata into the gino engine. Something that is otherwise completely unavailable
Either way, since gino does not support reflection and inspection, if I needed functions for those classes I would have to use sqlalchemy, which means I'd end up creating multiple engines and running synchronous code which thoroughly defeats the purpose of using gino in the first place

[wwwjfy]

To clarify, the function signature is not the same (missing schema in this PR) and the SQL statements are different.
I mean either we don't have them at all, or we behave the same.

Something that is otherwise completely unavailable

You can still execute raw SQL using gino as the same as what is done in this PR.

[maestro-1]

Okay, I understand, I guess that means I'll have to ensure that they are all the same because I really do want those functions available. I'd rather not have the write specific SQL queries every time I want to get database metadata while working with gino

[wwwjfy]

I'd keep the function in a util package which accepts connection object to return the result.

[maestro-1]

original that was the plan, but

1. those are not the only functions of sqlalchemy unavailable in gino
2. It would be less than optimal to rewrite those functions and a utils module for every project I undertake that requires those functions while working with gino.

[wwwjfy]

I think it depends on the functions you refer to. Unlike SQLAlchemy a complete ORM, gino is trying to be lightweight and explicit. We will see a lot of sqlalchemy features not here, especially ORM-related ones.
(not saying that we shouldn't have any utility functions, we can have get_table_names, just that I think it's better to be consistent with sqlalchemy signature)

In your case, if it's common to multiple projects, it's also an option to have a common package every project and import and use.

[maestro-1]

I am not trying to turn gino into a complete ORM. I just wanted a few metadata, like available public tables, table constraints, oids, and the likes. The problem is that these functions are already available in GINO via inheritance from SQLalchemy. But then when you try to use those functions an error occurs, which is definitely not the best.
I understand the reason for gino not wanting to get bloated and want to be mostly compatible with sqlalchemy which explains the absence of the reflection class and the inspection class. I closed this PR but I am working on another to help completely piggyback on the dialect class of sqlalchemy without throwing an error due to the use of GinoConnection instead of SqlalchemyConnection class.

[wwwjfy]

I agree gino has a long way to go to provide enough functions for general usage.
I just wanted to reiterate because there were asks for ORM features.
Looking forward to your PR. :)