New to the boards and have just begun planning my 1st spatial project in years, so i was looking into your original question yesterday, which was a great refresher for me on: the OGC standards; the GDAL/OGR, GEOS, and PostGIS geospatial libraries; and the Google Developers docs.
I was surprised to see that GIS folks are still hacking away to extract/convert KML but (given the nature of spatially-enabled XML which allows for geometries of different type & extent to spread out across multiple folders, tucked in among representation parameters and Earth viewer settings) it was clear after an hour of digging that data tools have matured nicely since I was last in the game.
I think the you can update via ogr2ogr but may have to wrap it in the "-sql" option if you opt not to use "-update -append". About the -append -overwrite -update options: I have confused these SOFTWARE TOOL NAMES with their every day meanings for years (yikes) until grasping their dependent/independent functionality...today. Per the docs:
-append: Append to existing layer instead of creating new
-overwrite: Delete the output layer and recreate it empty
-update: Open existing output datasource in update mode rather than trying to create a new one
I scratched my head looking at website sample use cases until the answer appeared (where else?) on the Boston GIS OGR2OGR Cheatsheet, which says:
Note in the above we needed to put the -update -append option because
OGR2OGR will try to create a folder if given a file with no extension,
which translates to creating a new database.
I knew it wasn't possible to create a new PostgreSQL DB with ogr2ogr. Going back to the definitions, it's super clear that -append and -overwrite refer to layers while -update refers to the data source. That's why we can see the table-level options with the db-level, and we never see -update on its own.
Whew. Back to the update PG DB from KML issue. It appears there are several different combinations of tools (-SELECT with a join, -SELECT with -WHERE, -sql, -fieldmap, etc.) that will succeed but i'll have to edit later with some samples that account for the xml structure of the data were shredding for the update.
EDIT: There may be two steps required after all, given that the -update option points to the data source and not the table itself. So something like:
ogr2ogr -update -append frontend_pct -sql "SELECT boundary FROM <path to>myfile.kml LEFT JOIN OUTER JOIN frontend_pct ON frontend_pct.code = myfile.kml.ID" PG:"host=127.0.0.1 dbname='$DB_NAME' user='$DB_USER' password='$DB_NAME'" myfile.kml
will probably either fail or create new records, blank except for geometries. One very surprising possibility, however, invokes ogrinfo instead of ogr2ogr:
ogrinfo frontend_pct -dialect SQLite -sql "SELECT boundary FROM <path to>myfile.kml LEFT JOIN OUTER JOIN frontend_pct ON frontend_pct.code = myfile.kml.ID" PG:"host=127.0.0.1 dbname='$DB_NAME' user='$DB_USER' password='$DB_NAME'" -dialect SQLite -sql "UPDATE frontend_pct SET boundary = <work out path to/parsing of kml> (SELECT boundary FROM <path to>myfile.kml) WHERE frontend_pct.code = myfile.kml.ID
Never worked in SQLite so you'll have to work out the query, but I think you might actually get a one-step update using ogrinfo instead of ogr2ogr. Surprising.