|From:||Julien Rouhaud <rjuju123(at)gmail(dot)com>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Gilles Darold <gilles(at)darold(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Add a pg_get_query_def function (was Re: Deparsing rewritten query)|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Sun, Mar 27, 2022 at 11:53:58AM -0400, Tom Lane wrote:
> Julien Rouhaud <rjuju123(at)gmail(dot)com> writes:
> > [ v4-0001-Add-a-pg_get_query_def-wrapper-around-get_query_d.patch ]
> This seems about ready to go to me, except for
> (1) as an exported API, pg_get_querydef needs a full API spec in its
> header comment. "Read the code to figure out what to do" is not OK
> in my book.
> (2) I don't think this has been thought out too well:
> > I also kept the wrapColument and startIdent as they
> > can be easily used by callers.
> The appropriate values for these are determined by macros that are
> local in ruleutils.c, so it's not that "easy" for outside callers
> to conform to standard practice. I suppose we could move
> WRAP_COLUMN_DEFAULT etc into ruleutils.h, but is there actually a
> use-case for messing with those?
As far as I can see the wrapColumn and startIndent are independant of the
pretty flags, and don't really have magic numbers for those
(WRAP_COLUMN_DEFAULT sure exists, but the value isn't really surprising).
> I don't see any other exported
> functions that go beyond offering a "bool pretty" option, so
> I think it might be a mistake for this one to be different.
There's the SQL function pg_get_viewdef_wrap() that accept a custom wrapColumn.
That being said I'm totally ok with just exposing a "pretty" parameter and use
WRAP_COLUMN_DEFAULT. In any case I agree that exposing startIndent doesn't
serve any purpose.
I'm attaching a v5 with hopefully a better comment for the function, and only
the "pretty" parameter.
|Next Message||Michael Paquier||2022-03-28 03:12:48||Re: Add pg_freespacemap extension sql test|
|Previous Message||David G. Johnston||2022-03-28 03:12:16||Re: Document atthasmissing default optimization avoids verification table scan|