Thread

Commits

  1. Improve coverage of cpluspluscheck.

  2. Fix C++ incompatibilities in ecpg/preproc/ header files.

  3. Fix C++ incompatibilities in plpgsql's header files.

  4. Fix assorted header files that failed to compile standalone.

  5. Make our perfect hash functions be valid C++.

  1. compiling PL/pgSQL plugin with C++

    Тарасов Георгий Витальевич <tarasov-g@gaz-is.ru> — 2019-05-30T15:14:01Z

    Dear all,
    
    I'm working on development of some PL/pgSQL plugin.
    The smaller part of my code is written on C.
    It's a standard extension code for integration with fmgr (_PG_init ...)
    
    But bigger part of the code is written on C++. 
    And here I need declarations of internal PL/pgSQL structs from plpgsql.h
    
    Direct include of this file to my C++ code results in the following errors:
    
    
    /opt/pgsql-11/include/server/plpgsql.h:1201:45: ошибка: expected <,> or <...> before <new>
     extern void plpgsql_adddatum(PLpgSQL_datum *new);
                                                 ^
    /opt/pgsql-11/include/server/plpgsql.h:1228:15: ошибка: expected <,> or <...> before <typeid>
              Oid *typeid, int32 *typmod, Oid *collation);
                   ^
    
    It's obviously that this code can't be compiled with C++ because the
    C++ keywords are used as an identifiers. I modified plpgsql.h.
    So, please advise does the renaming is the right step in this situation??
    
    All my modifications are in the attached patch.
    Corrections are made also in C-files (pl_comp.c and pl_exec.c), where the function definitions are 
    located, but this is not necessarily.
    
    George
    
  2. Re: compiling PL/pgSQL plugin with C++

    Tom Lane <tgl@sss.pgh.pa.us> — 2019-05-30T15:54:24Z

    [ redirecting to -hackers ]
    
    =?koi8-r?B?9MHSwdPP1yDnxc/Sx8nKIPfJ1MHM2MXXyd4=?= <Tarasov-G@gaz-is.ru> writes:
    > I'm working on development of some PL/pgSQL plugin.
    > The smaller part of my code is written on C.
    > It's a standard extension code for integration with fmgr (_PG_init ...)
    > But bigger part of the code is written on C++. 
    > And here I need declarations of internal PL/pgSQL structs from plpgsql.h
    
    So ... that's supposed to work, because we have a test script that
    verifies that all our headers compile as C++.
    
    Or I thought it was "all", anyway.  Closer inspection shows that it's
    not checking src/pl.  Nor contrib.
    
    I propose that we change src/tools/pginclude/cpluspluscheck so that
    it searches basically everywhere:
     
    -for f in `find src/include src/interfaces/libpq/libpq-fe.h src/interfaces/libpq/libpq-events.h -name '*.h' -print | \
    +for f in `find src contrib -name '*.h' -print | \
    
    However, trying to run that, I find that plpython and plperl are both
    seriously in violation of the project convention that headers should
    compile standalone.  It looks like most of their headers rely on an
    assumption that the calling .c file already included the Python or
    Perl headers respectively.
    
    Anybody object to me reshuffling the #include's to make this pass?
    I propose doing that for HEAD only, although we should back-patch
    George's fix (and any other actual C++ problems we find).
    
    			regards, tom lane
    
    
    
    
  3. Re: compiling PL/pgSQL plugin with C++

    Tom Lane <tgl@sss.pgh.pa.us> — 2019-05-30T21:46:28Z

    I wrote:
    > I propose that we change src/tools/pginclude/cpluspluscheck so that
    > it searches basically everywhere:
     
    > -for f in `find src/include src/interfaces/libpq/libpq-fe.h src/interfaces/libpq/libpq-events.h -name '*.h' -print | \
    > +for f in `find src contrib -name '*.h' -print | \
    
    After further experimentation with that, it seems like we'll have
    to continue to exclude src/bin/pg_dump/*.h from the C++ check.
    pg_dump uses "public" and "namespace" as field names in various
    structs, both of which are C++ keywords.  Changing these names
    would be quite invasive, and at least in the short run I see no
    payoff for doing so.
    
    ecpg/preproc/type.h is also using "new" as a field name, but it
    looks like there are few enough references that renaming that
    field isn't unreasonable.
    
    There are various other minor issues, but they generally look
    fixable with little consequence.
    
    			regards, tom lane
    
    
    
    
  4. Re: compiling PL/pgSQL plugin with C++

    Tom Lane <tgl@sss.pgh.pa.us> — 2019-05-31T21:39:44Z

    I wrote:
    > There are various other minor issues, but they generally look
    > fixable with little consequence.
    
    I've now pushed your patch and additional minor fixes, and
    we've expanded cpluspluscheck's coverage so we don't miss
    such issues in future.
    
    			regards, tom lane