ecpg.sgml: the the -> the--- doc/src/sgml/ecpg.sgml.orig 2012-03-11 10:15:20.0 +0100
+++ doc/src/sgml/ecpg.sgml 2012-03-11 10:15:37.0 +0100
@@ -4038,7 +4038,7 @@
sqlname
-The the name of the field.
+The name of the field.
On 2012-03-10 10:39, I wrote:
I can probably write some docs tomorrow.
Attached is v5 of the patch, with is exactly equal to v4 but with added
documentation.
Some other notes.
- Robert asked why sepgsql_setcon with NULL to reset the value to the
initial client label was supported. Maybe
On 2012-03-11 11:33, Yeb Havinga wrote:
On 2012-03-10 10:39, I wrote:
I can probably write some docs tomorrow.
Attached is v5 of the patch, with is exactly equal to v4 but with
added documentation.
s/cube(1) == '(1)'// in that patch please
--
Sent via pgsql-hackers mailing list (pgsql
On Sun, Mar 11, 2012 at 11:25:01AM +0100, Erik Rijkers wrote:
> ecpg.sgml: the the -> the
Fixed, thanks for spotting this.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: m
On sön, 2012-03-11 at 00:34 -0500, Tom Lane wrote:
> I think it'd be useful to print CPPFLAGS, CFLAGS, and LDFLAGS if the
> environment is supplying values for them (or maybe print their values
> after absorbing whatever is in the buildfarm animal's config).
> Peter might know whether there's anyth
On 03/11/2012 08:00 AM, Peter Eisentraut wrote:
On sön, 2012-03-11 at 00:34 -0500, Tom Lane wrote:
I think it'd be useful to print CPPFLAGS, CFLAGS, and LDFLAGS if the
environment is supplying values for them (or maybe print their values
after absorbing whatever is in the buildfarm animal's co
Unless I misunderstood the documentation I think this fixes a typo. Thanks :)
From a36150c67f526cdcc9dee826dd7f69bb9b06498f Mon Sep 17 00:00:00 2001
From: Thomas Hunger
Date: Sun, 11 Mar 2012 12:13:21 +
Subject: [PATCH] Use user_name like the Synopsis does.
---
doc/src/sgml/ref/create_databa
Hello
create table t1(d date, n integer);
postgres=# insert into t1 select '2001-01-01', 1 from generate_series(1,3);
INSERT 0 3
but
postgres=# insert into t1 select distinct '2001-01-01', 1 from
generate_series(1,3);
ERROR: column "d" is of type date but expression is of type text
LINE 1: ins
Hi Robert
2012/3/11 Robert Haas :
> On Sat, Mar 10, 2012 at 4:35 PM, Stefan Keller wrote:
>> The main conclusion was:
>> * Do a "tar cf /dev/zero $PG_DATA/base either shortly before or
>> shortly after the database is created"
>> * Do a seq scan "SELECT * FROM osm_point".
>>
>> Is your tool a rep
Pavel Stehule wrote:
> create table t1(d date, n integer);
>
> postgres=# insert into t1 select '2001-01-01', 1 from
> generate_series(1,3);
> INSERT 0 3
>
> but
>
> postgres=# insert into t1 select distinct '2001-01-01', 1 from
> generate_series(1,3);
> ERROR: column "d" is of type date but exp
Pavel Stehule writes:
> postgres=# insert into t1 select distinct '2001-01-01', 1 from
> generate_series(1,3);
> ERROR: column "d" is of type date but expression is of type text
> LINE 1: insert into t1 select distinct '2001-01-01', 1 from generate...
>^
>
Hello
2012/3/11 Kevin Grittner :
> Pavel Stehule wrote:
>
>> create table t1(d date, n integer);
>>
>> postgres=# insert into t1 select '2001-01-01', 1 from
>> generate_series(1,3);
>> INSERT 0 3
>>
>> but
>>
>> postgres=# insert into t1 select distinct '2001-01-01', 1 from
>> generate_series(1,3
2012/3/11 Tom Lane :
> Pavel Stehule writes:
>> postgres=# insert into t1 select distinct '2001-01-01', 1 from
>> generate_series(1,3);
>> ERROR: column "d" is of type date but expression is of type text
>> LINE 1: insert into t1 select distinct '2001-01-01', 1 from generate...
>>
Le vendredi 9 mars 2012 16:50:05, Robert Haas a écrit :
> On Fri, Mar 9, 2012 at 10:33 AM, Dimitri Fontaine
>
> wrote:
> > So that's complementary with pgfincore, ok. I still wish we could
> > maintain the RAM content HOT on the standby in the same way we are able
> > to maintain its data set on
Tom Lane writes:
> I don't want to have a server-side ticker at all, especially not one
> that exists only for a client that might or might not be there. We've
> been doing what we can to reduce PG's idle-power consumption, which is
> an important consideration for large-data-center applications.
On 03/10/2012 04:36 PM, Pavel Stehule wrote:
and there some cleaned version
Reran my tests and adjusted docs a bit, tbh I considered the previous
versions way more useful but even in this form it's nice and useful
functionality.
Regards
Petr Jelinek
plpgsql_check_function2.diff.gz
De
Thomas Hunger writes:
> Unless I misunderstood the documentation I think this fixes a typo. Thanks :)
Yeah, that should be consistent with the syntax summary. Applied,
thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
Cédric and Robert
Thanks, Cédric, for the reminder.
Would be nice to sort out the features of the two Postgres extentions
pgfincore (https://github.com/klando/pgfincore ) and pg_prewarm: what
do they have in common, what is complementary?
I would be happy to test both. But when reading the curre
On Sat, Mar 10, 2012 at 2:38 PM, Jaime Casanova wrote:
> On Fri, Mar 9, 2012 at 9:07 AM, Robert Haas wrote:
>> On Fri, Mar 9, 2012 at 12:47 AM, Jaime Casanova
>> wrote:
Sorry, here's the patch rebased and with the suggestion from Alex.
Which reminds me, I never thank him for the revie
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
>> [ tgl's redesign of spgist vacuum algorithm ]
> with a concurrent split moving leaf tuples between pages, can't it make
> bulkdelete fail reporting some TIDs
Yeah, you're right :-(. I've been chewing on this problem for awhile
and I think I se
On Sun, Mar 11, 2012 at 12:55 PM, Robert Haas wrote:
> I've finally been able to run some more tests of the effect of
> adjusting wal_buffers to values higher than 16MB. I ran the test on
> the 16 core (x 4 hw threads/core) IBM POWER7 machine, with my usual
> configuration settings:
>
> shared_bu
(2012/03/09 23:48), Tom Lane wrote:
> Etsuro Fujita writes:
Thank you for your answer.
>> 1. FilefdwPlanState.pages and FileFdwPlanState.ntuples seems redundant.
>>Why not use RelOptInfo.pages and RelOptInfo.tuples?
>
> I intentionally avoided setting RelOptInfo.pages because that would hav
2012/3/11 Petr Jelinek :
> On 03/10/2012 04:36 PM, Pavel Stehule wrote:
>>
>> and there some cleaned version
>>
>>
>
>
> Reran my tests and adjusted docs a bit, tbh I considered the previous
> versions way more useful but even in this form it's nice and useful
> functionality.
thank you - this ver
23 matches
Mail list logo
