On Sat, Oct 24, 2009 at 9:50 PM, Tom Lane wrote:
> Robert Haas writes:
>> I don't believe that the *ability* to have comments is the problem.
>> It wouldn't hurt anything to ship a file with a general comment block
>> at the top, with whatever content someone wants to put there. What
>> makes it
Magnus Hagander writes:
> 2009/10/24 Simon Riggs :
>> Could we have a new directive in postgresql.conf that allows you to
>> specify an includedirectory? Like an include directive but for a whole
>> directory rather than just a file.
> We could do it that way, but that would make the change bigge
Robert Haas writes:
> I don't believe that the *ability* to have comments is the problem.
> It wouldn't hurt anything to ship a file with a general comment block
> at the top, with whatever content someone wants to put there. What
> makes it impossible to machine-edit this file is that there is a
On Sat, Oct 24, 2009 at 7:38 PM, Tom Lane wrote:
> Robert Haas writes:
>> Supporting an include-directory seems harmless to me, and even
>> potentially useful. But the only way to solve the problem of
>> machine-parsing the config file is to remove the instructions (which
>> can only EVER be par
On Sat, 24 Oct 2009, Robert Haas wrote:
But the only way to solve the problem of machine-parsing the config file
is to remove the instructions (which can only EVER be parsed by human
beings) and put them somewhere else.
Ah, back to this again already. Your suggestion presumes there is someon
Robert Haas writes:
> Supporting an include-directory seems harmless to me, and even
> potentially useful. But the only way to solve the problem of
> machine-parsing the config file is to remove the instructions (which
> can only EVER be parsed by human beings) and put them somewhere else.
Uh, t
The attached WIP patch revises EvalPlanQual processing along the lines
I've been muttering about for the last little while. It's a fairly
large patch, but it should be a lot more efficient than the existing
code as well as delivering much saner behavior. The key points are:
1. In order to avoid
2009/10/23 João Eugenio Marynowski
> I thought this would solve my problems but not yet ...
> the block that I found is not presenting error...
> find_bad_block
>
> (514708,16)
> (1 registro)
> blockId / blocks_per_chunk = 514708 / 131072 = 3,9269104
> base/21058/21271.3
> chun
On ons, 2009-10-21 at 13:11 +0900, Itagaki Takahiro wrote:
> So, we should always ignore BOM sequence
> at the file head no matter what client encoding is used.
I think we can't do that. That byte sequence might be valid user data
in other encodings.
--
Sent via pgsql-hackers mailing list (pgs
On Oct 24, 2009, at 4:01 PM, Dimitri Fontaine
wrote:
Le 24 oct. 2009 à 20:10, Robert Haas a écrit
:
$PGDATA/postgresql.conf
I think the multiple files should go in $PGDATA/postgresql.conf.d
But the only way to solve the problem of
machine-parsing the config file is to remove the instruct
> "James" == James Pye writes:
James> Is the new date_recv() constraint actually correct?
No, it's not:
regression=# create table x (a date);
CREATE TABLE
regression=# insert into x values ('1999-01-01');
INSERT 0 1
regression=# copy x to '/tmp/tst.dmp' binary;
COPY 1
regression=# copy x f
Still on the phone...
--
dim
Le 23 oct. 2009 à 21:16, Tom Lane a écrit :
I'd feel more comfortable with being able to add some flags to an
opclass (or more likely an opfamily) that assert that its strategy
numbers agree with some convention or other.
The overlap operator only concern mult
phone answering, please forgive style...
--
dim
Le 24 oct. 2009 à 20:10, Robert Haas a écrit :
$PGDATA/postgresql.conf
I think the multiple files should go in $PGDATA/postgresql.conf.d
But the only way to solve the problem of
machine-parsing the config file is to remove the instructions
On Sat, Oct 24, 2009 at 9:41 AM, Magnus Hagander wrote:
> Per discussion at the developer meeting back in Ottawa, attached is an
> initial patch that implements reading a directory of configuration
> files instead of just one. The idea being that something like a tuning
> tool, or pgadmin, for exa
On Sat, 24 Oct 2009, Andrew Dunstan wrote:
If we're going to do this at all, ISTM the location should be configurable,
just like other file locations are.
...
What bothers me some is that it sounds like a bit of a footgun. A postgres
cluster is a shared resource, and we surely don't want appli
On Fri, Oct 16, 2009 at 01:38:15PM +0300, Peter Eisentraut wrote:
> I like the new Unicode tables, but the marking of continuation lines
> looks pretty horrible:
>
> List of databases
> Name │ Owner │ Encoding │ Collation │ Ctype │ Access
> privileges
> ─
On Sat, 2009-10-24 at 18:57 +0200, Magnus Hagander wrote:
>> That's basically what it does now, except
> >> it doesn't add a parameter in postgresql.conf. If you lkeave the
> >> pg_config directory empty, it will just parse the postgresql.conf file
> >> just like before, and that's it. only if you
On Sat, 2009-10-24 at 12:52 -0400, Andrew Dunstan wrote:
> What bothers me some is that it sounds like a bit of a footgun. A
> postgres cluster is a shared resource, and we surely don't want
> applications meddling with the shared config. This seems quite different
> from, say, an application d
2009/10/24 Simon Riggs :
> On Sat, 2009-10-24 at 18:34 +0200, Magnus Hagander wrote:
>
>> Did you look at the patch?
>
> I did, yes. But no docs with it. It would be good to see the proposal,
> not just the patch (or a reference to the written proposal from
> earlier).
We discussed it at the devel
Magnus Hagander wrote:
I'm happy with the new feature, however, so is there a way to do this?
Could we have a new directive in postgresql.conf that allows you to
specify an includedirectory? Like an include directive but for a whole
directory rather than just a file.
We could do it that
On Sat, 2009-10-24 at 18:34 +0200, Magnus Hagander wrote:
> Did you look at the patch?
I did, yes. But no docs with it. It would be good to see the proposal,
not just the patch (or a reference to the written proposal from
earlier).
> That's basically what it does now, except
> it doesn't add a
2009/10/24 Simon Riggs :
> On Sat, 2009-10-24 at 15:41 +0200, Magnus Hagander wrote:
>
>> Per discussion at the developer meeting back in Ottawa, attached is an
>> initial patch that implements reading a directory of configuration
>> files instead of just one. The idea being that something like a t
2009/10/24 Grzegorz Jaskiewicz :
>
> On 24 Oct 2009, at 14:41, Magnus Hagander wrote:
>
>> Per discussion at the developer meeting back in Ottawa, attached is an
>> initial patch that implements reading a directory of configuration
>> files instead of just one. The idea being that something like a
On Aug 31, 2009, at 1:12 AM, Heikki Linnakangas wrote:
...
Is the new date_recv() constraint actually correct?
[looking at the "result < 0" part, at least]
src/backend/utils/adt/date.c
...
+ /* Limit to the same range that date_in() accepts. */
+ if (result < 0 || result > JULIAN
On Sat, 2009-10-24 at 15:41 +0200, Magnus Hagander wrote:
> Per discussion at the developer meeting back in Ottawa, attached is an
> initial patch that implements reading a directory of configuration
> files instead of just one. The idea being that something like a tuning
> tool, or pgadmin, for e
On 24 Oct 2009, at 14:41, Magnus Hagander wrote:
Per discussion at the developer meeting back in Ottawa, attached is an
initial patch that implements reading a directory of configuration
files instead of just one. The idea being that something like a tuning
tool, or pgadmin, for example can dro
Per discussion at the developer meeting back in Ottawa, attached is an
initial patch that implements reading a directory of configuration
files instead of just one. The idea being that something like a tuning
tool, or pgadmin, for example can drop and modify files in this
directory instead of modif
27 matches
Mail list logo
