Re: Adding SHOW CREATE TABLE

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Kirk Wolak <wolakk(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Adding SHOW CREATE TABLE
Date: 2023-05-22 09:24:21
Message-ID: CAFj8pRBhJxOcdFUzcG4wdQZoFA1ffkCt6z6xkD13QPN4qea3eQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

po 22. 5. 2023 v 7:19 odesílatel Kirk Wolak <wolakk(at)gmail(dot)com> napsal:

> On Fri, May 19, 2023 at 1:08 PM Andrew Dunstan <andrew(at)dunslane(dot)net>
> wrote:
>
>> I think the ONLY place we should have this is in server side functions.
>> More than ten years ago I did some work in this area (see below), but it's
>> one of those things that have been on my ever growing personal TODO list
>>
>> See <https://bitbucket.org/adunstan/retailddl/src/master/>
>> <https://bitbucket.org/adunstan/retailddl/src/master/> and
>> <https://www.youtube.com/watch?v=fBarFKOL3SI>
>> <https://www.youtube.com/watch?v=fBarFKOL3SI>
>>
> Andrew,
> Thanks for sharing that. I reviewed your code. 10yrs, clearly it's not
> working (as-is, but close), something interesting about the
> structure you ended up in. You check the type of the object and redirect
> accordingly at the top level. Hmmm...
> What I liked was that each type gets handled (I was focused on "table"),
> but I realized similarities.
>
> I don't know what the group would think, but I like the thought of
> calling this, and having it "Correct" to call the appropriate function.
> But not sure it will stand. It does make obvious that some of these
> should be spun out as "pg_get_typedef"..
> pg_get_typedef
> pg_get_domaindef
> pg_get_sequencedef
>
> Finally, since you started this a while back, part of me is "leaning"
> towards a function:
> pg_get_columndef
>
> Which returns a properly formatted column for a table, type, or domain?
> (one of the reasons for this, is that this is
> the function with the highest probability to change, and potentially the
> easiest to share reusability).
>
> Finally, I am curious about your opinion. I noticed you used the
> internal pg_ tables, versus the information_schema...
> I am *thinking* that the information_schema will be more stable over
> time... Thoughts?
>

I think inside the core, the information schema is never used. And there
was a performance issue (fixed in PostgreSQL 12), that blocked index usage.

Regards

Pavel

> Thank you for sharing your thoughts...
> Kirk...
>
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Owen Stephens 2023-05-22 11:36:22 Re: Unexpected cross-database vacuum impact with hot_standby_feedback=on
Previous Message Ron 2023-05-22 07:08:53 Re: DBeaver postgres localhost access

Browse pgsql-hackers by date

  From Date Subject
Next Message torikoshia 2023-05-22 09:24:49 Re: Allow pg_archivecleanup to remove backup history files
Previous Message Alvaro Herrera 2023-05-22 09:16:09 Re: Naming of gss_accept_deleg