From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Kirk Wolak <wolakk(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Adding SHOW CREATE TABLE |
Date: | 2023-05-22 11:52:24 |
Message-ID: | c82340a1-d893-3018-0d61-22966851d1e0@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On 2023-05-22 Mo 05:24, Pavel Stehule wrote:
>
>
> 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.
>
>
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
From | Date | Subject | |
---|---|---|---|
Next Message | Joseph Hammerman | 2023-05-22 13:46:02 | Fwd: PGCon remote attendance |
Previous Message | Owen Stephens | 2023-05-22 11:36:22 | Re: Unexpected cross-database vacuum impact with hot_standby_feedback=on |
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2023-05-22 12:11:14 | Re: createuser --memeber and PG 16 |
Previous Message | Alvaro Herrera | 2023-05-22 11:49:47 | Re: pgbench: using prepared BEGIN statement in a pipeline could cause an error |