New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add PostGIS #709
Add PostGIS #709
Conversation
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. |
Filled in the CLA form. Let me know if anything else is needed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CLA for @robe2 looks good.
I've got a comment about build.sh, feel free to address it later. merging now.
Thanks!
make -j$(nproc) -s | ||
cd .. | ||
|
||
./fuzzers/build_google_oss_fuzzers.sh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should work as is, but it's preferable to have the fuzz targets built as part of the regular developer build (make
).
Otherwise the risk is that the fuzz targets will often bit rot and we will see failures only on oss-fuzz
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it should be part of make
but it's ok for it to be part of a separate target (make fuzzers
?) -- especially as the path to that script may change (I find fuzzers
to be too generic of a name, when other fuzzers do exist)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
make fuzzers
, make fuzz_targets
, or some such would be great.
What we are tying to encourage is that the fuzz targets become part of the project's continuous integration process, even w/o actually fuzzing.
Read more at https://github.com/google/oss-fuzz/blob/master/docs/ideal_integration.md
* Add postgis to projects * Update project.yaml * Update Dockerfile * have it pull default branch
From https://postgis.net:
"""PostGIS adds support for geographic objects to the PostgreSQL object-relational database. In effect, PostGIS "spatially enables" the PostgreSQL server, allowing it to be used as a backend spatial database for geographic information systems (GIS), much like ESRI's SDE or Oracle's Spatial extension. PostGIS follows the OpenGIS "Simple Features Specification for SQL" and has been certified as compliant with the "Types and Functions" profile. """
PostGIS is GPL licensed.
The created fuzzers are for the liblwgeom sub-component of PostGIS that has functions that receive arbitrary user data. They have already been committed in https://git.osgeo.org/gogs/postgis/postgis/src/svn-trunk/fuzzers