Re: SQL/MED compatible connection manager - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: SQL/MED compatible connection manager
Date
Msg-id 49425F36.2040007@gmx.net
Whole thread Raw
In response to Re: SQL/MED compatible connection manager  (Martin Pihlak <martin.pihlak@gmail.com>)
Responses Re: SQL/MED compatible connection manager  (Martin Pihlak <martin.pihlak@gmail.com>)
Re: SQL/MED compatible connection manager  (Martin Pihlak <martin.pihlak@gmail.com>)
Re: SQL/MED compatible connection manager  ("Jonah H. Harris" <jonah.harris@gmail.com>)
List 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?


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: WIP: default values for function parameters
Next
From: Tom Lane
Date:
Subject: Re: Mostly Harmless: Welcoming our C++ friends