On Mon, Mar 28, 2022 at 11:20:42AM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
> > I'm attaching a v5 with hopefully a better comment for the function, and
> > only
> > the "pretty" parameter.
>
> Pushed with some minor cosmetic adjustments.
Thanks a lot!
I just published an extension usin
Julien Rouhaud writes:
> I'm attaching a v5 with hopefully a better comment for the function, and only
> the "pretty" parameter.
Pushed with some minor cosmetic adjustments.
regards, tom lane
On Sun, Mar 27, 2022 at 11:53:58AM -0400, Tom Lane wrote:
> Julien Rouhaud 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.
Julien Rouhaud 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
On Fri, Mar 25, 2022 at 05:49:04PM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
> > I'm attaching the correct patch this time, sorry about that.
>
> While I'm okay with this in principle, as it stands it fails
> headerscheck/cpluspluscheck:
>
> $ src/tools/pginclude/headerscheck
> In file in
Julien Rouhaud writes:
> I'm attaching the correct patch this time, sorry about that.
While I'm okay with this in principle, as it stands it fails
headerscheck/cpluspluscheck:
$ src/tools/pginclude/headerscheck
In file included from /tmp/headerscheck.Oi8jj3/test.c:2:
./src/include/utils/ruleuti
On Fri, Feb 04, 2022 at 12:45:05PM +0100, Pavel Stehule wrote:
>
> ok, I don't have any problem with it. Then there is not necessarily any
> change, and I'll mark this patch as ready for committer.
Thanks Pavel!
I also realized that the CF entry description wasn't accurate anymore, so I
also fix
pá 4. 2. 2022 v 10:36 odesílatel Julien Rouhaud napsal:
> Hi,
>
> On Wed, Feb 02, 2022 at 07:49:41PM +0100, Pavel Stehule wrote:
> >
> > I checked this trivial patch, and I don't see any problem. Again I run
> > check-world with success. The documentation for this feature is not
> > necessary. Bu
Hi,
On Wed, Feb 02, 2022 at 07:49:41PM +0100, Pavel Stehule wrote:
>
> I checked this trivial patch, and I don't see any problem. Again I run
> check-world with success. The documentation for this feature is not
> necessary. But I am not sure about regress tests. Without any other code,
> enfosing
st 2. 2. 2022 v 15:18 odesílatel Julien Rouhaud napsal:
> Hi,
>
> On Tue, Feb 01, 2022 at 08:35:00PM +0100, Pavel Stehule wrote:
> >
> > I tested your patch, and it looks so it is working without any problem.
> All
> > tests passed.
> >
> > There is just one question. If printalias = true will be
Hi,
On Tue, Feb 01, 2022 at 08:35:00PM +0100, Pavel Stehule wrote:
>
> I tested your patch, and it looks so it is working without any problem. All
> tests passed.
>
> There is just one question. If printalias = true will be active for all
> cases or just with some flag?
Sorry, as I just replied
Hi,
On Wed, Feb 02, 2022 at 07:09:35PM +0530, Bharath Rupireddy wrote:
> On Tue, Feb 1, 2022 at 9:08 AM Julien Rouhaud wrote:
> >
> > Hi,
>
> Thanks. +1 for this work. Some comments on v3:
>
> 1) How about pg_get_rewritten_query()?
Argh, I just realized that I sent the patch from the wrong bra
On Tue, Feb 1, 2022 at 9:08 AM Julien Rouhaud wrote:
>
> Hi,
Thanks. +1 for this work. Some comments on v3:
1) How about pg_get_rewritten_query()?
2) Docs missing?
3) How about allowing only the users who are explicitly granted to use
this function like pg_log_backend_memory_contexts,
pg_log_que
út 1. 2. 2022 v 4:38 odesílatel Julien Rouhaud napsal:
> Hi,
>
> On Mon, Jan 31, 2022 at 10:05:44PM +0100, Pavel Stehule wrote:
> >
> > I don't feel good about forcing an alias. relname doesn't ensure
> > uniqueness. You can have two views with the same name from different
> > schemas. Moreover t
Hi,
On Mon, Jan 31, 2022 at 10:05:44PM +0100, Pavel Stehule wrote:
>
> I don't feel good about forcing an alias. relname doesn't ensure
> uniqueness. You can have two views with the same name from different
> schemas. Moreover this field is necessary only when a deparsed query is
> printed, not a
po 31. 1. 2022 v 19:09 odesílatel Julien Rouhaud
napsal:
> Hi,
>
> On Mon, Jan 31, 2022 at 06:46:37PM +0100, Pavel Stehule wrote:
> >
> > I checked the last patch. I think it is almost trivial. I miss just
> > comment, why this alias is necessary
> >
> > + if (!rte->alias)
> > + rte->alias = mak
Hi,
On Mon, Jan 31, 2022 at 06:46:37PM +0100, Pavel Stehule wrote:
>
> I checked the last patch. I think it is almost trivial. I miss just
> comment, why this alias is necessary
>
> + if (!rte->alias)
> + rte->alias = makeAlias(get_rel_name(rte->relid), NULL);
Thanks for looking at it Pavel!
Hi
po 31. 1. 2022 v 15:37 odesílatel Gilles Darold napsal:
> Le 28/06/2021 à 18:41, Julien Rouhaud a écrit :
> > Thanks for the feedback Gilles!
> >
> > On Mon, Jun 28, 2021 at 04:06:54PM +0200, Gilles Darold wrote:
> >> If we could at least call get_query_def()through an extension if we
> didn'
Le 28/06/2021 à 18:41, Julien Rouhaud a écrit :
> Thanks for the feedback Gilles!
>
> On Mon, Jun 28, 2021 at 04:06:54PM +0200, Gilles Darold wrote:
>> If we could at least call get_query_def()through an extension if we didn't
>> have a functionit would be ideal for DBAs.I agree this is unusual but
Thanks for the feedback Gilles!
On Mon, Jun 28, 2021 at 04:06:54PM +0200, Gilles Darold wrote:
>
> If we could at least call get_query_def()through an extension if we didn't
> have a functionit would be ideal for DBAs.I agree this is unusual but when
> it does happen to you being able to call get
Le 27/06/2021 à 17:14, Tom Lane a écrit :
Julien Rouhaud writes:
On Sun, Jun 27, 2021 at 10:34:52AM -0400, Tom Lane wrote:
It's not very hard to imagine someday moving view
expansion into the planner on efficiency grounds, leaving the rewriter
handling only the rare uses of INSERT/UPDATE/DELET
On Sun, Jun 27, 2021 at 11:14:05AM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
>
> > Agreed. One the other hand having such a function in core may ensure that
> > any
> > significant change in those area will keep an API to retrieve the final
> > query
> > representation.
>
> My point is
Julien Rouhaud writes:
> On Sun, Jun 27, 2021 at 10:34:52AM -0400, Tom Lane wrote:
>> It's not very hard to imagine someday moving view
>> expansion into the planner on efficiency grounds, leaving the rewriter
>> handling only the rare uses of INSERT/UPDATE/DELETE rules.
> Agreed. One the other
On Sun, Jun 27, 2021 at 10:34:52AM -0400, Tom Lane wrote:
>
> I'm not really excited by this, as it seems like it's exposing internal
> decisions we could change someday; to wit, first that there is any such
> thing as a separate rewriting pass
Sure, but the fact that views will significantly imp
Julien Rouhaud writes:
> As an alternative, maybe we could expose a simple SRF that would take care of
> rewriting the query and deparsing the resulting query tree(s)?
I'm not really excited by this, as it seems like it's exposing internal
decisions we could change someday; to wit, first that the
On Sun, Jun 27, 2021 at 10:06:00AM -0300, Ranier Vilela wrote:
>
> 1. strcmp(sql, "") could not be replaced by sql[0] == '\0'?
It's a debugging leftover that I forgot to remove. There's no point trying
to catch an empty string as e.g. a single space would be exactly the same, and
both would be c
> Hi,
>
> I sometimes have to deal with queries referencing multiple and/or complex
> views. In such cases, it's quite troublesome to figure out what is the
> query
> really executed. Debug_print_rewritten isn't really useful for non trivial
> queries, and manually doing the view expansion isn't gr
ne 27. 6. 2021 v 6:11 odesílatel Julien Rouhaud napsal:
> Hi,
>
> I sometimes have to deal with queries referencing multiple and/or complex
> views. In such cases, it's quite troublesome to figure out what is the
> query
> really executed. Debug_print_rewritten isn't really useful for non trivi
Hi,
I sometimes have to deal with queries referencing multiple and/or complex
views. In such cases, it's quite troublesome to figure out what is the query
really executed. Debug_print_rewritten isn't really useful for non trivial
queries, and manually doing the view expansion isn't great either.
29 matches
Mail list logo
