2011/10/10 pasman pasmański pasma...@gmail.com:
Attached patch.
... and what are these new options intended to do?
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
At a quick glance, this patch seems to have an issue about priority.
Which value is used if an option has been set both on a foreign table
and a foreign server?
Also I think documents and regression tests would be required for
this kind of change.
Regards,
--
Shigeru Hanada
--
Sent via
On Mon, Oct 10, 2011 at 10:51:03PM +0900, Shigeru Hanada wrote:
At a quick glance, this patch seems to have an issue about priority.
Which value is used if an option has been set both on a foreign table
and a foreign server?
I believe that the finer-grained setting should always override the
On 10/10/2011 09:51 AM, Shigeru Hanada wrote:
At a quick glance, this patch seems to have an issue about priority.
Which value is used if an option has been set both on a foreign table
and a foreign server?
Also I think documents and regression tests would be required for
this kind of change.
Hi.
Current behaviour is error message when foreign table and foreign
server have the same option defined.
I don't know how to write regression test, may i read about it somewhere?
--
pasman
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Mon, Oct 10, 2011 at 10:23:51AM -0400, Andrew Dunstan wrote:
On 10/10/2011 09:51 AM, Shigeru Hanada wrote:
At a quick glance, this patch seems to have an issue about priority.
Which value is used if an option has been set both on a foreign table
and a foreign server?
Also I think
On 10/10/2011 11:59 AM, David Fetter wrote:
On Mon, Oct 10, 2011 at 10:23:51AM -0400, Andrew Dunstan wrote:
On 10/10/2011 09:51 AM, Shigeru Hanada wrote:
At a quick glance, this patch seems to have an issue about priority.
Which value is used if an option has been set both on a foreign table
