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
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
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:
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
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.
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,
>
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
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
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
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,
ú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
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
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 =
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
>
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
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
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
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
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
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
> 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
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
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
29 matches
Mail list logo
