Greetings,
* Nathaniel Sabanski (sabanski.n@gmail.com) wrote:
> > Perhaps a bit more discussion about what exactly the use-case is would
> > be helpful- what would you use this feature for?
>
> App writers: To facilitate table creation and simplify schema verification,
> without relying on a GUI tool or ORM (or system calls out to pg_dump).
Not sure how it would simplify schema verification?
> Tool writers: Would drastically cut down the implementation time and
> complexity to support Postgres. I am one of the devs of Piccolo ORM (Python
> lib supporting Postgres) and we have a lot of code dedicated to
> re-generating the CREATE TABLE statements (creation, during migrations,
> etc) that could be done better by Postgres itself.
I'm curious- have you compared what you're doing to pg_dump's output?
Are you confident that there aren't any distinctions between those that,
for whatever reason, need to exist?
> Moving to Postgres: It would help ease migrations for developers wanting to
> move from MySQL / Percona / MariaDB to Postgres. Also it's a nice developer
> experience to see how Postgres generates X table without extra tooling.
Seems unlikely that this would actually be all that helpful there- tools
like ora2pg and similar know how to query other database systems and
write appropriate CREATE TABLE statements for PostgreSQL.
> The intention of SHOW CREATE TABLE is not to replace the existing suite of
> \d in psql but rather to be a developer friendly complement within SQL
> itself.
Sure, I get that.
Again, would be great to see someone actually work on this. There's
already a good chunk of code in core in pg_dump and in the postgres_fdw
for doing exactly this and it'd be great to consolidate that and at the
same time expose it via SQL.
Another possible option would be to add this to libpq, which is used by
postgres_fdw, psql, pg_dump, and lots of other drivers and client
utilities. If it's all broadly the same, personally I'd prefer it to be
in the common library and available as a backend SQL command too, but
perhaps there's reasons that it would be easier to implement in libpq
instead.
Thanks,
Stephen