Обсуждение: [PATCH] Tab completion for ALTER DATABASE … SETTABLESPACE

Hi hackers,

I just noticed that psql's tab completion for ALTER TABLE … SET
TABLESPACE was treating it as any other configuration parameter and
completing with FROM DEFAULT or TO after it, instead of a list of
tablespaces.

PFA a patch that fixes this.

- ilmari
-- 
"A disappointingly low fraction of the human race is,
 at any given time, on fire." - Stig Sandbeck Mathisen

From a72d9dc1f38606a0bca8ff29b561915b8cbe9d5c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dagfinn=20Ilmari=20Manns=C3=A5ker?= <ilmari@ilmari.org>
Date: Thu, 30 Aug 2018 17:36:16 +0100
Subject: [PATCH] =?UTF-8?q?Fix=20tab=20completion=20for=20ALTER=20TABLE=20?=
 =?UTF-8?q?=E2=80=A6=20SET=20TABLESPACE?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

It was being treated as any other configuration parameter.
---
 src/bin/psql/tab-complete.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
index bb696f8ee9..f107ffb027 100644
--- a/src/bin/psql/tab-complete.c
+++ b/src/bin/psql/tab-complete.c
@@ -1783,6 +1783,10 @@ psql_completion(const char *text, int start, int end)
                             "IS_TEMPLATE", "ALLOW_CONNECTIONS",
                             "CONNECTION LIMIT");
 
+    /* ALTER DATABASE <name> SET TABLESPACE */
+    else if (Matches5("ALTER", "DATABASE", MatchAny, "SET", "TABLESPACE"))
+        COMPLETE_WITH_QUERY(Query_for_list_of_tablespaces);
+
     /* ALTER EVENT TRIGGER */
     else if (Matches3("ALTER", "EVENT", "TRIGGER"))
         COMPLETE_WITH_QUERY(Query_for_list_of_event_triggers);
-- 
2.18.0

ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes:

> Hi hackers,
>
> I just noticed that psql's tab completion for ALTER TABLE … SET
> TABLESPACE was treating it as any other configuration parameter and
> completing with FROM DEFAULT or TO after it, instead of a list of
> tablespaces.

And just after hitting send, I noticed I'd typed ALTER TABLE instead of
ALTER DATABASE, including in the commit message :(

Fixed patch attached.

- ilmari 
-- 
"I use RMS as a guide in the same way that a boat captain would use
 a lighthouse.  It's good to know where it is, but you generally
 don't want to find yourself in the same spot." - Tollef Fog Heen

From e5ff67c3284dd456fe80ed8a8927e12665d68fea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dagfinn=20Ilmari=20Manns=C3=A5ker?= <ilmari@ilmari.org>
Date: Thu, 30 Aug 2018 17:36:16 +0100
Subject: [PATCH] =?UTF-8?q?Fix=20tab=20completion=20for=20ALTER=20DATABASE?=
 =?UTF-8?q?=20=E2=80=A6=20SET=20TABLESPACE?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

It was being treated as any other configuration parameter.
---
 src/bin/psql/tab-complete.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
index bb696f8ee9..f107ffb027 100644
--- a/src/bin/psql/tab-complete.c
+++ b/src/bin/psql/tab-complete.c
@@ -1783,6 +1783,10 @@ psql_completion(const char *text, int start, int end)
                             "IS_TEMPLATE", "ALLOW_CONNECTIONS",
                             "CONNECTION LIMIT");
 
+    /* ALTER DATABASE <name> SET TABLESPACE */
+    else if (Matches5("ALTER", "DATABASE", MatchAny, "SET", "TABLESPACE"))
+        COMPLETE_WITH_QUERY(Query_for_list_of_tablespaces);
+
     /* ALTER EVENT TRIGGER */
     else if (Matches3("ALTER", "EVENT", "TRIGGER"))
         COMPLETE_WITH_QUERY(Query_for_list_of_event_triggers);
-- 
2.18.0

Hello,

On Thu, Aug 30, 2018 at 05:54:23PM +0100, Dagfinn Ilmari Mannsåker wrote:
> ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> > Hi hackers,
> >
> > I just noticed that psql's tab completion for ALTER TABLE … SET
> > TABLESPACE was treating it as any other configuration parameter and
> > completing with FROM DEFAULT or TO after it, instead of a list of
> > tablespaces.
> 
> And just after hitting send, I noticed I'd typed ALTER TABLE instead of
> ALTER DATABASE, including in the commit message :(
> 
> Fixed patch attached.

+1. Attached patch works nicely. It applies using "patch".

-- 
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

On Thu, Aug 30, 2018 at 05:54:23PM +0100, Dagfinn Ilmari Mannsåker wrote:
> ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> > Hi hackers,
> >
> > I just noticed that psql's tab completion for ALTER TABLE … SET
> > TABLESPACE was treating it as any other configuration parameter and
> > completing with FROM DEFAULT or TO after it, instead of a list of
> > tablespaces.
> 
> And just after hitting send, I noticed I'd typed ALTER TABLE instead of
> ALTER DATABASE, including in the commit message :(
> 
> Fixed patch attached.

The patch seems reasonable. It fixes the lack of tab completion for
ALTER DATABASE ... SET TABLESPACE ... .

There is no need to patch the documentation and regression tests.

Marked as Ready for Commiter.

-- 
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

Arthur Zakirov <a.zakirov@postgrespro.ru> writes:
> On Thu, Aug 30, 2018 at 05:54:23PM +0100, Dagfinn Ilmari Mannsåker wrote:
>> And just after hitting send, I noticed I'd typed ALTER TABLE instead of
>> ALTER DATABASE, including in the commit message :(
>> Fixed patch attached.

> The patch seems reasonable. It fixes the lack of tab completion for
> ALTER DATABASE ... SET TABLESPACE ... .

LGTM too, pushed.

            regards, tom lane

On Fri, Sep 21, 2018 at 9:22 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Arthur Zakirov <a.zakirov@postgrespro.ru> writes:
> > On Thu, Aug 30, 2018 at 05:54:23PM +0100, Dagfinn Ilmari Mannsåker wrote:
> >> And just after hitting send, I noticed I'd typed ALTER TABLE instead of
> >> ALTER DATABASE, including in the commit message :(
> >> Fixed patch attached.
>
> > The patch seems reasonable. It fixes the lack of tab completion for
> > ALTER DATABASE ... SET TABLESPACE ... .
>
> LGTM too, pushed.

+   else if (Matches5("ALTER", "DATABASE", MatchAny, "SET", "TABLESPACE"))

. o O ( hmm, we now have variadic macros )

--
Thomas Munro
http://www.enterprisedb.com

Thomas Munro <thomas.munro@enterprisedb.com> writes:
> . o O ( hmm, we now have variadic macros )

hmmm ... but even with variadic, C's macro facility is so weak that
I'm not sure we can reimplement these with it.  What would the
expansion look like?

(It constantly annoys me that C's so weak here.  In the language
I used for my first for-pay programming work, Bliss/11, the macro
facility could have done that easily.  That was 45 years ago.)

            regards, tom lane

On 2018-09-20 18:38:36 -0400, Tom Lane wrote:
> Thomas Munro <thomas.munro@enterprisedb.com> writes:
> > . o O ( hmm, we now have variadic macros )
> 
> hmmm ... but even with variadic, C's macro facility is so weak that
> I'm not sure we can reimplement these with it.  What would the
> expansion look like?

There's a dirty hack to count arguments in vararg macros:
https://groups.google.com/d/msg/comp.std.c/d-6Mj5Lko_s/5fW1bP6T3RIJ

Afaict that ought to be enough to implement something like the current
macros? Whether that's too ugly or not, I don't know.


> It constantly annoys me that C's so weak here.

Yea. Weak and fragile, both.


Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> On 2018-09-20 18:38:36 -0400, Tom Lane wrote:
>> hmmm ... but even with variadic, C's macro facility is so weak that
>> I'm not sure we can reimplement these with it.  What would the
>> expansion look like?

> There's a dirty hack to count arguments in vararg macros:
> https://groups.google.com/d/msg/comp.std.c/d-6Mj5Lko_s/5fW1bP6T3RIJ

Doesn't seem to help for this case.  What we really want is to expand
a given pattern once for each variadic argument, and I don't see how
to get there from here.

Although maybe I'm thinking too much inside-the-box.  The expansion
doesn't necessarily have to be identical to the code the macros
generate today.  In fact, that code is kinda bulky.  I wonder if
we could go over to something involving a variadic function, or
maybe an array of string-pointer constants?

            regards, tom lane

On 2018-09-20 19:03:16 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2018-09-20 18:38:36 -0400, Tom Lane wrote:
> >> hmmm ... but even with variadic, C's macro facility is so weak that
> >> I'm not sure we can reimplement these with it.  What would the
> >> expansion look like?
> 
> > There's a dirty hack to count arguments in vararg macros:
> > https://groups.google.com/d/msg/comp.std.c/d-6Mj5Lko_s/5fW1bP6T3RIJ
> 
> Doesn't seem to help for this case.  What we really want is to expand
> a given pattern once for each variadic argument, and I don't see how
> to get there from here.

Depends on whether your goal is to simplify *using* the macro, or the
infrastructure for the macro.  Afaict it should be relatively
straightforward to use a, possibly simplified, macro like referenced
above to have TailMatches(...), TailMatchesCS(...), Matches(...) that
then expand to the current *N macros.


> Although maybe I'm thinking too much inside-the-box.  The expansion
> doesn't necessarily have to be identical to the code the macros
> generate today.  In fact, that code is kinda bulky.  I wonder if
> we could go over to something involving a variadic function, or
> maybe an array of string-pointer constants?

Yea, that might be a way to simplify both the macros and the use of the
macros.  Assuming we have something like PP_NARG, ISTM it should be
relatively straightforward to define something like

#define Matches(...) CheckMatchesFor(PP_NARG(__VA_ARGS__), __VA_ARGS__)

and then have a CheckMatchesFor() first check previous_words_count, and
then just have a simple for loop through previous_words[] - afaict the
number of arguments ought to suffice to make that possible?

Greetings,

Andres Freund

On 2018-09-20 16:19:26 -0700, Andres Freund wrote:
> On 2018-09-20 19:03:16 -0400, Tom Lane wrote:
> > Andres Freund <andres@anarazel.de> writes:
> > > On 2018-09-20 18:38:36 -0400, Tom Lane wrote:
> > >> hmmm ... but even with variadic, C's macro facility is so weak that
> > >> I'm not sure we can reimplement these with it.  What would the
> > >> expansion look like?
> > 
> > > There's a dirty hack to count arguments in vararg macros:
> > > https://groups.google.com/d/msg/comp.std.c/d-6Mj5Lko_s/5fW1bP6T3RIJ
> > 
> > Doesn't seem to help for this case.  What we really want is to expand
> > a given pattern once for each variadic argument, and I don't see how
> > to get there from here.
> 
> Depends on whether your goal is to simplify *using* the macro, or the
> infrastructure for the macro.  Afaict it should be relatively
> straightforward to use a, possibly simplified, macro like referenced
> above to have TailMatches(...), TailMatchesCS(...), Matches(...) that
> then expand to the current *N macros.
> 
> 
> > Although maybe I'm thinking too much inside-the-box.  The expansion
> > doesn't necessarily have to be identical to the code the macros
> > generate today.  In fact, that code is kinda bulky.  I wonder if
> > we could go over to something involving a variadic function, or
> > maybe an array of string-pointer constants?
> 
> Yea, that might be a way to simplify both the macros and the use of the
> macros.  Assuming we have something like PP_NARG, ISTM it should be
> relatively straightforward to define something like
> 
> #define Matches(...) CheckMatchesFor(PP_NARG(__VA_ARGS__), __VA_ARGS__)
> 
> and then have a CheckMatchesFor() first check previous_words_count, and
> then just have a simple for loop through previous_words[] - afaict the
> number of arguments ought to suffice to make that possible?

Here's a very quick-and-dirty implementation of this approach. Some very
very brief testing seems to indicate it works, although I'm sure not
perfectly.

The current duplication of the new functions doing the actual checking
(like CheckMatchesFor(), CheckTailMatchesFor()) would probably need to
be reduced. But I don't want to invest actual time before we decide that
this could be something we'd actually want to pursue.

Greetings,

Andres Freund

On Fri, Sep 21, 2018 at 5:52 PM Andres Freund <andres@anarazel.de> wrote:
> Here's a very quick-and-dirty implementation of this approach. Some very
> very brief testing seems to indicate it works, although I'm sure not
> perfectly.
>
> The current duplication of the new functions doing the actual checking
> (like CheckMatchesFor(), CheckTailMatchesFor()) would probably need to
> be reduced. But I don't want to invest actual time before we decide that
> this could be something we'd actually want to pursue.

+1

And here is a quick-and-dirty variadic COMPLETE_WITH(...).  Together:

    else if (Matches("PREPARE", MatchAny, "AS"))
        COMPLETE_WITH("SELECT", "UPDATE", "INSERT", "DELETE FROM");

+ * Making C pretty by making it ugly again.

Heh.

-- 
Thomas Munro
http://www.enterprisedb.com

Thomas Munro <thomas.munro@enterprisedb.com> writes:
> On Fri, Sep 21, 2018 at 5:52 PM Andres Freund <andres@anarazel.de> wrote:
>> Here's a very quick-and-dirty implementation of this approach. Some very
>> very brief testing seems to indicate it works, although I'm sure not
>> perfectly.

> And here is a quick-and-dirty variadic COMPLETE_WITH(...).  Together:

I'm a bit inclined to get rid of the need for PP_NARG() by instead making
the macros add a trailing NULL argument, viz

#define TailMatches(...) \
  CheckTailMatchesFor(previous_words_count, previous_words, __VA_ARGS__, NULL)

This'd require (some of) the implementation functions to iterate over
their variadic arguments twice, the first time merely counting how many
there are.  But we aren't exactly concerned about max runtime performance
here, and the PP_NARG() thing seems like a crock that could easily blow
out compilation time on some compilers.

If people are OK with that design decision, I'm happy to assemble these
pieces and push it through.  I just had to add two more versions of
HeadMatchesN :-( so I'm feeling motivated to make something happen.

            regards, tom lane

Hi,

On 2018-09-21 16:20:42 -0400, Tom Lane wrote:
> Thomas Munro <thomas.munro@enterprisedb.com> writes:
> > On Fri, Sep 21, 2018 at 5:52 PM Andres Freund <andres@anarazel.de> wrote:
> >> Here's a very quick-and-dirty implementation of this approach. Some very
> >> very brief testing seems to indicate it works, although I'm sure not
> >> perfectly.
> 
> > And here is a quick-and-dirty variadic COMPLETE_WITH(...).  Together:
> 
> I'm a bit inclined to get rid of the need for PP_NARG() by instead making
> the macros add a trailing NULL argument, viz
> 
> #define TailMatches(...) \
>   CheckTailMatchesFor(previous_words_count, previous_words, __VA_ARGS__, NULL)

I don't think that'd *quite* work right now - MatchAny is also NULL. We
probably could make it work by redefining either MatchAny or the last
argument to CheckTailMatchesFor() to some other value however.


> This'd require (some of) the implementation functions to iterate over
> their variadic arguments twice, the first time merely counting how many
> there are.

Yea, leaving the above problem aside, I've a hard time to get excited
about that overhead.


> But we aren't exactly concerned about max runtime performance
> here, and the PP_NARG() thing seems like a crock that could easily blow
> out compilation time on some compilers.

It's not actually that complicated an expansion, and we've not
encountered many problems with expansions that are similarly complex,
e.g. ereport et al.  It's pretty likely at least as cheap as the current
approach, where we sometimes have 9 deep recursion. So I'm not too
concerned about the compile-time performance. FWIW, I tested it with gcc
-E yesterday, and I couldn't measure any difference.

I think there's some argument to be made about the "mental" complexity
of the macros - if we went for them, we'd certainly need to add some
docs about how they work.  One argument for having PP_NARGS (renamed) is
that it doesn't seem useful just here, but in a few other cases as well.

Greetings,

Andres Freund

On Sat, Sep 22, 2018 at 8:51 AM Andres Freund <andres@anarazel.de> wrote:
> I think there's some argument to be made about the "mental" complexity
> of the macros - if we went for them, we'd certainly need to add some
> docs about how they work.  One argument for having PP_NARGS (renamed) is
> that it doesn't seem useful just here, but in a few other cases as well.

It's a nice general facility to have in the tree.  It seems to compile
OK on clang, gcc, MSVC (I added this thread as CF entry 20/1798 as a
lazy way to see if AppVeyor would build it OK, and it worked fine
until conflicting commits landed).  I wonder if xlc, icc, aCC and Sun
Studio can grok it.

--
Thomas Munro
http://www.enterprisedb.com

Hi,

On 2018-09-22 09:15:27 +1200, Thomas Munro wrote:
> On Sat, Sep 22, 2018 at 8:51 AM Andres Freund <andres@anarazel.de> wrote:
> > I think there's some argument to be made about the "mental" complexity
> > of the macros - if we went for them, we'd certainly need to add some
> > docs about how they work.  One argument for having PP_NARGS (renamed) is
> > that it doesn't seem useful just here, but in a few other cases as well.
> 
> It's a nice general facility to have in the tree.  It seems to compile
> OK on clang, gcc, MSVC (I added this thread as CF entry 20/1798 as a
> lazy way to see if AppVeyor would build it OK, and it worked fine
> until conflicting commits landed).  I wonder if xlc, icc, aCC and Sun
> Studio can grok it.

I think unless $compiler doesn't correctly implement vararg macros, it
really should just work.  There's nothing but pretty smart use of
actually pretty plain vararg macros.  If any of the other compilers have
troubles with that, they'd really not implement vararg macros...

Greetings,

Andres Freund

On Sat, Sep 22, 2018 at 9:46 AM Andres Freund <andres@anarazel.de> wrote:
> On 2018-09-22 09:15:27 +1200, Thomas Munro wrote:
> > On Sat, Sep 22, 2018 at 8:51 AM Andres Freund <andres@anarazel.de> wrote:
> > > I think there's some argument to be made about the "mental" complexity
> > > of the macros - if we went for them, we'd certainly need to add some
> > > docs about how they work.  One argument for having PP_NARGS (renamed) is
> > > that it doesn't seem useful just here, but in a few other cases as well.
> >
> > It's a nice general facility to have in the tree.  It seems to compile
> > OK on clang, gcc, MSVC (I added this thread as CF entry 20/1798 as a
> > lazy way to see if AppVeyor would build it OK, and it worked fine
> > until conflicting commits landed).  I wonder if xlc, icc, aCC and Sun
> > Studio can grok it.
>
> I think unless $compiler doesn't correctly implement vararg macros, it
> really should just work.  There's nothing but pretty smart use of
> actually pretty plain vararg macros.  If any of the other compilers have
> troubles with that, they'd really not implement vararg macros...

I vote for doing it this way then.  It may turn out to be useful for
efficient SearchSysCache(...), DirectFunctionCall(...) and other
things like that.

-- 
Thomas Munro
http://www.enterprisedb.com

Andres Freund <andres@anarazel.de> writes:
> On 2018-09-22 09:15:27 +1200, Thomas Munro wrote:
>> On Sat, Sep 22, 2018 at 8:51 AM Andres Freund <andres@anarazel.de> wrote:
>>> I think there's some argument to be made about the "mental" complexity
>>> of the macros - if we went for them, we'd certainly need to add some
>>> docs about how they work.  One argument for having PP_NARGS (renamed) is
>>> that it doesn't seem useful just here, but in a few other cases as well.

If you want to rename it, then to what?  VA_ARGS_NARGS, perhaps?

>> It's a nice general facility to have in the tree.

Yeah, that's a fair point.

>> It seems to compile
>> OK on clang, gcc, MSVC (I added this thread as CF entry 20/1798 as a
>> lazy way to see if AppVeyor would build it OK, and it worked fine
>> until conflicting commits landed).  I wonder if xlc, icc, aCC and Sun
>> Studio can grok it.

> I think unless $compiler doesn't correctly implement vararg macros, it
> really should just work.

Well, we'd find out pretty quickly if we try to use it here.

            regards, tom lane

On 2018-09-21 18:00:35 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2018-09-22 09:15:27 +1200, Thomas Munro wrote:
> >> On Sat, Sep 22, 2018 at 8:51 AM Andres Freund <andres@anarazel.de> wrote:
> >>> I think there's some argument to be made about the "mental" complexity
> >>> of the macros - if we went for them, we'd certainly need to add some
> >>> docs about how they work.  One argument for having PP_NARGS (renamed) is
> >>> that it doesn't seem useful just here, but in a few other cases as well.
> 
> If you want to rename it, then to what?  VA_ARGS_NARGS, perhaps?

I like your suggestion. I mainly didn't like the PP_ prefix.


> >> It's a nice general facility to have in the tree.
> 
> Yeah, that's a fair point.
> 
> >> It seems to compile
> >> OK on clang, gcc, MSVC (I added this thread as CF entry 20/1798 as a
> >> lazy way to see if AppVeyor would build it OK, and it worked fine
> >> until conflicting commits landed).  I wonder if xlc, icc, aCC and Sun
> >> Studio can grok it.
> 
> > I think unless $compiler doesn't correctly implement vararg macros, it
> > really should just work.
> 
> Well, we'd find out pretty quickly if we try to use it here.

You earlier were talking about tackling this - do you still want to? I
can otherwise, but it'll not be today, but likely tomorrow.

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> On 2018-09-21 18:00:35 -0400, Tom Lane wrote:
>> If you want to rename it, then to what?  VA_ARGS_NARGS, perhaps?

> I like your suggestion. I mainly didn't like the PP_ prefix.

Sold.  The original author overcomplicated it anyway; I now have

/*
 * VA_ARGS_NARGS
 *        Returns the number of macro arguments it is passed.
 *
 * An empty argument still counts as an argument, so effectively, this is
 * "one more than the number of commas in the argument list".
 *
 * This works for up to 63 arguments.  Internally, VA_ARGS_NARGS_() is passed
 * 64+N arguments, and the C99 standard only requires macros to allow up to
 * 127 arguments, so we can't portably go higher.  The implementation is
 * pretty trivial: VA_ARGS_NARGS_() returns its 64th argument, and we set up
 * the call so that that is the appropriate one of the list of constants.
 */
#define VA_ARGS_NARGS(...) \
    VA_ARGS_NARGS_(__VA_ARGS__, \
                   63,62,61,60,                   \
                   59,58,57,56,55,54,53,52,51,50, \
                   49,48,47,46,45,44,43,42,41,40, \
                   39,38,37,36,35,34,33,32,31,30, \
                   29,28,27,26,25,24,23,22,21,20, \
                   19,18,17,16,15,14,13,12,11,10, \
                   9, 8, 7, 6, 5, 4, 3, 2, 1, 0)
#define VA_ARGS_NARGS_( \
    _01,_02,_03,_04,_05,_06,_07,_08,_09,_10, \
    _11,_12,_13,_14,_15,_16,_17,_18,_19,_20, \
    _21,_22,_23,_24,_25,_26,_27,_28,_29,_30, \
    _31,_32,_33,_34,_35,_36,_37,_38,_39,_40, \
    _41,_42,_43,_44,_45,_46,_47,_48,_49,_50, \
    _51,_52,_53,_54,_55,_56,_57,_58,_59,_60, \
    _61,_62,_63,  N, ...) \
    (N)

from which it's pretty obvious that this really is a simple macro
call.  I'd first thought it involved macro recursion, but it doesn't.

> You earlier were talking about tackling this - do you still want to? I
> can otherwise, but it'll not be today, but likely tomorrow.

On it now.

            regards, tom lane

Hi,

On 2018-09-21 19:27:48 -0400, Tom Lane wrote:
> > You earlier were talking about tackling this - do you still want to? I
> > can otherwise, but it'll not be today, but likely tomorrow.
> 
> On it now.

Thanks, looks good.  msvc and icc are, as expected, ok too.

Greetings,

Andres Freund

Hi,

On 2018-09-22 09:56:00 +1200, Thomas Munro wrote:
> I vote for doing it this way then.  It may turn out to be useful for
> efficient SearchSysCache(...), DirectFunctionCall(...) and other
> things like that.

Yea, especially the *FunctionCall* stuff is awfully verbose.

I also wonder if it could make
http://archives.postgresql.org/message-id/20180605172952.x34m5uz6ju6enaem%40alap3.anarazel.de
a bit less painful.

Greetings,

Andres Freund