On 2023-05-22 Mo 05:24, Pavel Stehule wrote:


po 22. 5. 2023 v 7:19 odesílatel Kirk Wolak <wol...@gmail.com> napsal:

    On Fri, May 19, 2023 at 1:08 PM Andrew Dunstan
    <and...@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

Reply via email to