Re: [Postgres-xc-developers] SRF not working ?

[Michael P. <mic...@gm...>]

On Fri, Jul 5, 2013 at 1:23 PM, Ashutosh Bapat
<ash...@en...> wrote:
>
>
>
> On Thu, Jul 4, 2013 at 6:50 PM, Michael Paquier <mic...@gm...>
> wrote:
>>
>> On Thu, Jul 4, 2013 at 7:07 PM, Pavan Deolasee <pav...@gm...>
>> wrote:
>> >
>> > On Thu, Jul 4, 2013 at 3:21 PM, Michael Paquier
>> > <mic...@gm...>
>> >> generate_series has never been fixed for hash tables as far as I
>> >> recall.
>> > Hmm.. that could well be the case. I am immensely surprised and
>> > disappointed
>> > if that's true though. IMHO any PostgreSQL user will most likely fire
>> > that
>> > statement soon after creating a table to populate test data. It does not
>> > sound nice if the very first statement errors out.
>> +1.
>>
>> > What stops us from supporting that, except of course lack of development
>> > time?
>> That and the fact that such exceptions have never been considered a
>> high priority, I suppose. generate_series is the particular case of an
>> immutable function that cannot be FQS'ed for a non-replicated table. I
>> might be wrong, but I think it worked correctly for roundrobin.
>>
>
> I don't agree that it's because of immutability. It has more to do with the
> VALUES_RTE in INSERT statement. Any INSERT statement that is inserting more
> than one value in the distributed table can not be FQSed. In case there are
> more than one value being INSERTED through an INSERT statement, there are
> two RTEs in the query, one for the relation where INSERT is happening, and
> other for the values. So, I had implemented a simple rule in FQS
> shippability - if there are more than one RTEs in INSERT statement, do not
> FQS it. But I am unable to locate this rule now. Looks like while
> implementing something else, the rule has disappeared. And, since we do not
> have test for it, we didn't notice it.
Yeah you are right, sorry. This is not related to the immutability but
to the fact that the distribution column is used for such an INSERT.
--
Michael