On Thu, Sep 26, 2013 at 8:52 AM, Tom Lane wrote:
> Lonni J Friedman writes:
>> Thanks for your reply. This sounds like a relatively simple
>> workaround, so I'll give it a try. Is the search_path of the remote
>> session that postgres_fdw forces considered to be intentional,
>> expected behavio
Lonni J Friedman writes:
> Thanks for your reply. This sounds like a relatively simple
> workaround, so I'll give it a try. Is the search_path of the remote
> session that postgres_fdw forces considered to be intentional,
> expected behavior, or is it a bug?
It's intentional.
Possibly more to
Hi Shigeru,
Thanks for your reply. This sounds like a relatively simple
workaround, so I'll give it a try. Is the search_path of the remote
session that postgres_fdw forces considered to be intentional,
expected behavior, or is it a bug?
thanks!
On Wed, Sep 25, 2013 at 7:13 PM, Shigeru Hanada
Hi Lonni,
2013/9/25 Lonni J Friedman :
> The problem that I'm experiencing is if I attempt to perform an INSERT
> on the foreign nppsmoke table on cluster a, it fails claiming that the
> table partition which should hold the data in the INSERT does not
> exist:
>
> ERROR: relation "nppsmoke_2013_
Greetings,
I've got two different 9.3 clusters setup, a & b (on Linux if that
matters). On cluster b, I have a table (nppsmoke) that is partitioned
by date (month), which uses a function which is called by a trigger to
manage INSERTS (exactly as documented in the official documentation
for partiti
