David Fetter <david@fetter.org> writes:
> What happens now with dblink is that the remote table (more generally,
> the output of a fixed query) gets materialized into memory in its
> entirety, and if it's bigger than what's available, it will crash the
> backend or worse.
This is utter nonsense. It gets put into a tuplestore which is entirely
capable of spilling to disk. Slow, yes, but crashing is a lie.
> That happens because functions do not have any
> access to the predicates with which they were called, so the current
> workaround is to pass the predicates manually and then cast.
dblink is not a suitable framework for improving that situation.
Maybe someday we'll have a proper implementation of SQL/MED ...
regards, tom lane
