On Sunday, March 10, 2013 8:43 PM Greg Smith wrote:
> 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 try
Hi All,
Consider the following test:
postgres=# select version();
version
-
PostgreSQL 9.3devel on x86_64-unknown-linux-gnu, compiled by gcc (GCC)
4.4.6 20120305 (Red Hat 4.4.6-4), 6
On Sun, Mar 10, 2013 at 12:15 PM, Tom Lane 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.
>
> Hmm ...
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 incre
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 ta
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.
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 g
Thom Brown writes:
> On 10 March 2013 18:32, Tom Lane 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.
> postgres
Andrew Dunstan 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 that SELECT FOR UPDAT
On 10 March 2013 20:38, Thom Brown wrote:
> On 10 March 2013 18:32, Tom Lane wrote:
>> Kohei KaiGai 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
On 10 March 2013 18:32, Tom Lane wrote:
> Kohei KaiGai 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 fa
On 03/10/2013 02:32 PM, Tom Lane wrote:
Kohei KaiGai 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.
T
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,
Kohei KaiGai 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 here of course. O
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 to
On Sun, Jan 20, 2013 at 5:56 PM, Dean Rasheed wrote:
> On 5 January 2013 16:58, Magnus Hagander 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, and some code churn in the area, anothe
16 matches
Mail list logo
