pg.ddx.io pgsql-general@postgresql.org mailing list archive
help / color / mirror / Atom feedcompiling PL/pgSQL plugin with C++
4+ messages / 2 participants
[nested] [flat]
Commits from this thread:
2019-05-31 6f54b80edd Improve coverage of cpluspluscheck.
2019-05-31 4f67858d3f Fix C++ incompatibilities in ecpg/preproc/ header files.
2019-05-31 683c17b307 3f61b3205f 312017fcc4 db5d99916e c332c94adb da53e4f93f Fix C++ incompatibilities in plpgsql's header files.
2019-05-31 7640f93123 Fix assorted header files that failed to compile standalone.
2019-05-31 9e58705a7f Make our perfect hash functions be valid C++.
* compiling PL/pgSQL plugin with C++
@ 2019-05-30 15:14 Тарасов Георгий Витальевич <Tarasov-G@gaz-is.ru>
0 siblings, 1 reply; 4+ messages in thread
From: Тарасов Георгий Витальевич @ 2019-05-30 15:14 UTC (permalink / raw)
To: pgsql-general
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
Attachments:
rename-args-looks-like-cpp-keywords.patch (application/octet-stream, 3.6K) download
diff --git a/src/pl/plpgsql/src/pl_comp.c b/src/pl/plpgsql/src/pl_comp.c
index 59460d2643..85721bf735 100644
--- a/src/pl/plpgsql/src/pl_comp.c
+++ b/src/pl/plpgsql/src/pl_comp.c
@@ -2203,7 +2203,7 @@ plpgsql_start_datums(void)
* ----------
*/
void
-plpgsql_adddatum(PLpgSQL_datum *new)
+plpgsql_adddatum(PLpgSQL_datum *dobj)
{
if (plpgsql_nDatums == datums_alloc)
{
@@ -2211,8 +2211,8 @@ plpgsql_adddatum(PLpgSQL_datum *new)
plpgsql_Datums = repalloc(plpgsql_Datums, sizeof(PLpgSQL_datum *) * datums_alloc);
}
- new->dno = plpgsql_nDatums;
- plpgsql_Datums[plpgsql_nDatums++] = new;
+ dobj->dno = plpgsql_nDatums;
+ plpgsql_Datums[plpgsql_nDatums++] = dobj;
}
/* ----------
diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c
index 8f8f7efe44..eff434658d 100644
--- a/src/pl/plpgsql/src/pl_exec.c
+++ b/src/pl/plpgsql/src/pl_exec.c
@@ -5556,7 +5556,7 @@ plpgsql_exec_get_datum_type(PLpgSQL_execstate *estate,
void
plpgsql_exec_get_datum_type_info(PLpgSQL_execstate *estate,
PLpgSQL_datum *datum,
- Oid *typeid, int32 *typmod, Oid *collation)
+ Oid *typoid, int32 *typmod, Oid *collation)
{
switch (datum->dtype)
{
@@ -5565,7 +5565,7 @@ plpgsql_exec_get_datum_type_info(PLpgSQL_execstate *estate,
{
PLpgSQL_var *var = (PLpgSQL_var *) datum;
- *typeid = var->datatype->typoid;
+ *typoid = var->datatype->typoid;
*typmod = var->datatype->atttypmod;
*collation = var->datatype->collation;
break;
@@ -5578,13 +5578,13 @@ plpgsql_exec_get_datum_type_info(PLpgSQL_execstate *estate,
if (rec->erh == NULL || rec->rectypeid != RECORDOID)
{
/* Report variable's declared type */
- *typeid = rec->rectypeid;
+ *typoid = rec->rectypeid;
*typmod = -1;
}
else
{
/* Report record's actual type if declared RECORD */
- *typeid = rec->erh->er_typeid;
+ *typoid = rec->erh->er_typeid;
/* do NOT return the mutable typmod of a RECORD variable */
*typmod = -1;
}
@@ -5624,7 +5624,7 @@ plpgsql_exec_get_datum_type_info(PLpgSQL_execstate *estate,
recfield->rectupledescid = rec->erh->er_tupdesc_id;
}
- *typeid = recfield->finfo.ftypeid;
+ *typoid = recfield->finfo.ftypeid;
*typmod = recfield->finfo.ftypmod;
*collation = recfield->finfo.fcollation;
break;
@@ -5632,7 +5632,7 @@ plpgsql_exec_get_datum_type_info(PLpgSQL_execstate *estate,
default:
elog(ERROR, "unrecognized dtype: %d", datum->dtype);
- *typeid = InvalidOid; /* keep compiler quiet */
+ *typoid = InvalidOid; /* keep compiler quiet */
*typmod = -1;
*collation = InvalidOid;
break;
diff --git a/src/pl/plpgsql/src/plpgsql.h b/src/pl/plpgsql/src/plpgsql.h
index fb9fcb55f5..82b2950294 100644
--- a/src/pl/plpgsql/src/plpgsql.h
+++ b/src/pl/plpgsql/src/plpgsql.h
@@ -1198,7 +1198,7 @@ extern PLpgSQL_recfield *plpgsql_build_recfield(PLpgSQL_rec *rec,
extern int plpgsql_recognize_err_condition(const char *condname,
bool allow_sqlstate);
extern PLpgSQL_condition *plpgsql_parse_err_condition(char *condname);
-extern void plpgsql_adddatum(PLpgSQL_datum *new);
+extern void plpgsql_adddatum(PLpgSQL_datum *dobj);
extern int plpgsql_add_initdatums(int **varnos);
extern void plpgsql_HashTableInit(void);
@@ -1225,7 +1225,7 @@ extern Oid plpgsql_exec_get_datum_type(PLpgSQL_execstate *estate,
PLpgSQL_datum *datum);
extern void plpgsql_exec_get_datum_type_info(PLpgSQL_execstate *estate,
PLpgSQL_datum *datum,
- Oid *typeid, int32 *typmod, Oid *collation);
+ Oid *typoid, int32 *typmod, Oid *collation);
/*
* Functions for namespace handling in pl_funcs.c
* Re: compiling PL/pgSQL plugin with C++
@ 2019-05-30 15:54 Tom Lane <tgl@sss.pgh.pa.us>
parent: Тарасов Георгий Витальевич <Tarasov-G@gaz-is.ru>
0 siblings, 1 reply; 4+ messages in thread
From: Tom Lane @ 2019-05-30 15:54 UTC (permalink / raw)
To: Тарасов Георгий Витальевич <Tarasov-G@gaz-is.ru>; +Cc: pgsql-hackers@lists.postgresql.org
[ 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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: compiling PL/pgSQL plugin with C++
@ 2019-05-30 21:46 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 4+ messages in thread
From: Tom Lane @ 2019-05-30 21:46 UTC (permalink / raw)
To: pgsql-hackers@lists.postgresql.org; +Cc: Тарасов Георгий Витальевич <Tarasov-G@gaz-is.ru>
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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: compiling PL/pgSQL plugin with C++
@ 2019-05-31 21:39 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 4+ messages in thread
From: Tom Lane @ 2019-05-31 21:39 UTC (permalink / raw)
To: Тарасов Георгий Витальевич <Tarasov-G@gaz-is.ru>; +Cc: pgsql-hackers@lists.postgresql.org
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
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2019-05-31 21:39 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2019-05-30 15:14 compiling PL/pgSQL plugin with C++ Тарасов Георгий Витальевич <Tarasov-G@gaz-is.ru>
2019-05-30 15:54 ` Tom Lane <tgl@sss.pgh.pa.us>
2019-05-30 21:46 ` Tom Lane <tgl@sss.pgh.pa.us>
2019-05-31 21:39 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox