Another version of postgis reports another oid for geometry, 16396. This approach does not seem scalable. Perhaps theres a more portable way of doing this? Or maybe map every unknown oid to PersistentDbSpecific and let the PersistentField instance decide how to handle it?

I don't know the right way to handle this, it's really beyond my expertise with PostgreSQL.

According to Database.PostgreSQL.Simple.FromField's docs:

On the other hand if the type is provided by an extension, such as PostGIS or hstore, then the typeOid is not stable and can vary from database to database. In this case it is recommended that FromField instances use typename instead.

So it confirms that hardcoding the oid of extension types is doomed to failure.

Another way to support extension types could be by using the aforementioned typename that fname returns instead of the oid to dispatch (modifying getGetter accordingly).

However, I believe that mapping any unknown oid to a PersistentDbSpecific bytestring (as done in afea41e) is a better approach since any binary extension type can be supported this way provided a PersistentField instance can de/serialize to from/to it.

Thoughts?

I think that makes sense, though I'll admit that I'm a bit hazy on the details of what's going on here. If it works for your use case, and doesn't break the tests, I think it's OK to merge it in.

Let me rephrase that last one: can you confirm that this commit/PR solves the issue for you?

Oh, sorry if it wasn't clear. Yes it does. It's a fix I needed when trying to talk with the DB in production which has a different oid than the one i'm developing against and the one in travis (which motivated this PR)

Can you try running the persistent-test test suite with the -fpostgresql flag? It just segfaulted for me.

It also segfaults (randomly) on my system inside PQftable. According to gdb:

1. data type specs handles all types

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bbdff5 in ?? () from /usr/lib/libpq.so.5
(gdb) bt
#0 0x00007ffff7bbdff5 in ?? () from /usr/lib/libpq.so.5
#1 0x00007ffff7bbe0d2 in ?? () from /usr/lib/libpq.so.5
#2 0x00007ffff7bc0288 in PQftable () from /usr/lib/libpq.so.5
#3 0x0000000000c89817 in ?? ()
#4 0x0000000000000000 in ?? ()

However, it appears unrelated to this PR since the same segfault (ie: insisde PQftable) randomly occurs on the preceding revision (d7779b0) too. I've created #314 for it

I'm merging this in now, thank you. From what I can tell, it's working. I'll hold off on releasing until we resolve the segfault issue, and then can be more certain now regressions have been introduced.

Thanks!