On Sun, Jan 20, 2013 at 5:56 PM, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 5 January 2013 16:58, Magnus Hagander mag...@hagander.net wrote:
Attached is an updated version of the patch, per the comments from Tom
and rebased on top of the current master. Since it's been a long time
ago,
On 3/7/13 2:42 AM, Amit Kapila wrote:
I also think the tests added for regression may be more than required...
If you think above optimization's to reduce number of tests are okay, then I
will update the patch.
I was not trying to get you to remove regression tests. I was just
pointing out
Kohei KaiGai kai...@kaigai.gr.jp writes:
[ pgsql-v9.3-writable-fdw-poc.v12.part-1/2.patch ]
Applied after rather extensive editorialization. DELETE RETURNING in
particular was a mess, and I also tried to make SELECT FOR UPDATE behave
in what seemed like a sane fashion.
There's a lot left to do
I wrote:
There's a lot left to do here of course. One thing I was wondering
about was why we don't allow DEFAULTs to be attached to foreign-table
columns. There was no use in it before, but it seems sensible enough
now.
Hmm ... the buildfarm just rubbed my nose in a more immediate issue,
On 03/10/2013 02:32 PM, Tom Lane wrote:
Kohei KaiGai kai...@kaigai.gr.jp writes:
[ pgsql-v9.3-writable-fdw-poc.v12.part-1/2.patch ]
Applied after rather extensive editorialization. DELETE RETURNING in
particular was a mess, and I also tried to make SELECT FOR UPDATE behave
in what seemed
On 10 March 2013 18:32, Tom Lane t...@sss.pgh.pa.us wrote:
Kohei KaiGai kai...@kaigai.gr.jp writes:
[ pgsql-v9.3-writable-fdw-poc.v12.part-1/2.patch ]
Applied after rather extensive editorialization. DELETE RETURNING in
particular was a mess, and I also tried to make SELECT FOR UPDATE behave
On 10 March 2013 20:38, Thom Brown t...@linux.com wrote:
On 10 March 2013 18:32, Tom Lane t...@sss.pgh.pa.us wrote:
Kohei KaiGai kai...@kaigai.gr.jp writes:
[ pgsql-v9.3-writable-fdw-poc.v12.part-1/2.patch ]
Applied after rather extensive editorialization. DELETE RETURNING in
particular was
Andrew Dunstan and...@dunslane.net writes:
Excellent news. But I noticed as I went to update my non-writeable FDW
that this has happened in the regression tests. Is this correct?
Yeah, see the adjustment I made in the file_fdw test (which that looks
to be borrowed from).
The new theory is
Thom Brown t...@linux.com writes:
On 10 March 2013 18:32, Tom Lane t...@sss.pgh.pa.us wrote:
There's a lot left to do here of course. One thing I was wondering
about was why we don't allow DEFAULTs to be attached to foreign-table
columns. There was no use in it before, but it seems sensible
With 9.3devel, I can't seem to join a matview to a view; surely that should be
allowed?
Here is an example:
-8--
#!/bin/sh
echo
drop table if exists t1 cascade;
drop table if exists t2 cascade;
drop materialized view if exists mv ;
create table t1 as select chr(i) as c1, i from
On 03/10/2013 11:12 PM, Greg Smith wrote:
5) An error message appears every time you reload configuration, if
some part of the SET PERSISTENT mechanism isn't functional. This is
going to be too much for some people. And it's confusing when it
happens as part an interactive psql session. I
Hi,
I was checking code-coverage of 'make check' and saw that the regression
tests don't touch files like psql_help.c at all (read 0%).
Attached is a (very small) patch to work on one ABORT help function as a
sample.
The reason why I post this is, to know if increasing the code-coverage (as
a
Robins wrote:
Hi,
I was checking code-coverage of 'make check' and saw that the regression
tests don't touch files like psql_help.c at all (read 0%).
Attached is a (very small) patch to work on one ABORT help function as a
sample.
The reason why I post this is, to know if increasing
On Sun, Mar 10, 2013 at 12:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
There's a lot left to do here of course. One thing I was wondering
about was why we don't allow DEFAULTs to be attached to foreign-table
columns. There was no use in it before, but it seems sensible enough
now.
14 matches
Mail list logo
