Re: Adding SHOW CREATE TABLE

On 2023-05-22 Mo 05:24, Pavel Stehule wrote:
>
>
> po 22. 5. 2023 v 7:19 odesílatel Kirk Wolak <wolakk@gmail.com> napsal:
>
>     On Fri, May 19, 2023 at 1:08 PM Andrew Dunstan
>     <andrew@dunslane.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.
>
>

A performant server side set of functions would be written in C and 
follow the patterns in ruleutils.c.


cheers


andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com