From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SQL/MED compatible connection manager |
Date: | 2008-12-12 12:55:18 |
Message-ID: | 49425F36.2040007@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Now I have a question about the FDW C interface. The way I understand
it, an SQL/MED-enabled server and a FDW each have a specific API by
which they communicate. Supposedly, each database vendor should be able
to ship a binary library for its FDW and each SQL/MED-enabled server
should be able to load and use it. (If you don't believe in binary
compatibility, then I think there should at least be source-level
interface compatibility.)
Now the way I read the FDWs you provide (default and pgsql), you are
creating your own API for initialization and options validation that is
not in the standard. That would appear to contradict the idea of a
standard interface. I understand that option validation is useful, and
I don't see anything about it in the standard, but should we break the
API like that? What are your designs about this?
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-12-12 13:05:26 | Re: Mostly Harmless: Welcoming our C++ friends |
Previous Message | David E. Wheeler | 2008-12-12 12:50:37 | Re: WIP: default values for function parameters |