| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> | 
| Cc: | Ronan Dunklau <rdunklau(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: Arguments to foreign tables? | 
| Date: | 2012-11-06 17:57:37 | 
| Message-ID: | 16192.1352224657@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Tue, 2012-11-06 at 09:19 +0100, Ronan Dunklau wrote:
>> If you don't mind, do you have a specific use-case for this ?
> Let's say that your remote data source is a stream of data that is not
> actually being stored anywhere, e.g. network events. The data you want
> to retrieve are all events with a timestamp less than X, and you assume
> that the timestamp is monotonically increasing (so as soon as you get to
> X, the read is finished). 
> An SRF isn't good enough because it always materializes (and that's the
> only way it allows you to control initialization and teardown of the
> stream connection). But you don't want to have to define a new foreign
> table each time. It would be better if there were a way to pass the
> argument X to the FDW mechanism.
That particular example can be handled perfectly well today, with
select * from stream_table where tscol < 'whatever';
The FDW could be coded to throw an error if the query doesn't provide a
WHERE clause that constrains the timestamp column suitably.  It does
mean that you have to expose the "argument" as a result column, but at
least for this use-case that hardly seems like a problem.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-11-06 18:00:06 | Re: Proposal for Allow postgresql.conf values to be changed via SQL | 
| Previous Message | Tom Lane | 2012-11-06 17:51:04 | Re: [HACKERS] pg_dump and thousands of schemas |