On Tue, Feb 28, 2012 at 12:28 AM, Noah Misch wrote:
> On Mon, Feb 27, 2012 at 02:13:32PM +0200, Heikki Linnakangas wrote:
>> On 23.02.2012 18:01, Alvaro Herrera wrote:
>>> As far as complexity, yeah, it's a lot more complex now -- no question
>>> about that.
>>
>> How about assigning a new, real,
On 02/28/2012 04:52 AM, Rob Wultsch wrote:
On Wed, Feb 22, 2012 at 2:31 PM, james wrote:
Has anyone considered managing a system like the DragonFLY swapcache for a
DBMS like PostgreSQL?
https://www.facebook.com/note.php?note_id=388112370932
in the same vein:
http://bcache.evilpiepirate.o
(2012/02/25 7:31), Peter Eisentraut wrote:
> Could we name this "postgresql_fdw" instead? We already have several
> ${productname}_fdw out there, and I don't want to get in the business of
> having to guess variant spellings.
I worry name conflict with existing postgresql_fdw_validator, which is
2012/2/28 Tatsuo Ishii :
> Are you suggesting log_statement? I don't think it's a solution by
> following reasons:
>
> 1) it's slow to enable that on busy systems
> 2) tables affected by cascading delete/update/drop is not logged in
> PostgreSQL log
What about reading archived WAL files? They w
On Sun, Feb 26, 2012 at 8:53 AM, Euler Taveira de Oliveira
wrote:
> On 25-02-2012 09:23, Magnus Hagander wrote:
>> Do we even *need* the validate_xlog_location() function? If we just
>> remove those calls, won't we still catch all the incorrectly formatted
>> ones in the errors of the sscanf() cal
On Feb 27, 2012 10:36 PM, "Greg Smith" wrote:
> One of the reasons I drilled right into this spot is because of fears
that running the writer more often would sprout regressions in TPS. I
can't explain exactly why exactly having backends write their own buffers
out at the latest possible moment w
On Mon, Feb 27, 2012 at 4:24 AM, Magnus Hagander wrote:
> Hi!
>
> I admit to not having actually tested this since I don't have a good
> cluster to test it on right now, but from what I can tell the code in
> the new checkpointer process only sends statistics to the collector
> once the checkpoint
I noticed a misleading error message recently while using createdb. Try:
test=# CREATE ROLE dummy NOLOGIN;
Now, attempt to use createdb as that role. Here's 9.1.1:
$ createdb -Udummy testdb
createdb: could not connect to database postgres: FATAL: role "dummy"
is not permitted to log in
And her
2012/2/28 Tom Lane :
> Christopher Browne writes:
>> On Mon, Feb 27, 2012 at 6:20 PM, Tom Lane wrote:
>>> So, whatever the desirability of having them run as table owner,
>>> we can't just up and change that.
>
>> I'm inclined to hold to the argument that it Works Properly Now, and
>> that we sho
Excerpts from Noah Misch's message of sáb ene 14 12:20:18 -0300 2012:
> Occasionally, I have a SQL file destined for psql's \i command whose name
> contains a space. Less often, I'll have a .csv destined for \copy with the
> same problem. psql's filename completion does not handle these well. I
On Wed, Feb 22, 2012 at 2:31 PM, james wrote:
> Has anyone considered managing a system like the DragonFLY swapcache for a
> DBMS like PostgreSQL?
>
https://www.facebook.com/note.php?note_id=388112370932
--
Rob Wultsch
wult...@gmail.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
On 02/27/2012 03:24 PM, Jan Lentfer wrote:
And, yes.. it does effect pgsql performance on read loads seriously.
See BSD Mag 5/2011
http://bsdmag.org/magazine/1691-embedded-bsd-freebsd-alix
and
http://www.shiningsilence.com/dbsdlog/2011/04/12/7586.html
Caching on the read-only pgbench is a wel
Hi everybody.
I want to ask about hot-standby related issues. First of all, maybe I will
describe my scenario of Postgres master-slave.
1. There are Master A and Slave B in different location, assumed different
region of nation.
2. Configuring Master A and Slave B to become hot-standby is same as
Hello.
I will show you fixed version patch later, please wait for a
while.
==
> It's more important to not destabilize V3 code.
Ok, I withdraw that agreeing with that point. And I noticed that
the proposal before is totally a crap becuase I have mixed up
asyncStatus with resultStatus in it.
Excerpts from Tom Lane's message of lun feb 27 20:49:36 -0300 2012:
> So (assuming Peter has read the spec correctly) I'm coming around to the
> idea that the anonymous trigger functions created by this syntax ought
> to be "SECURITY DEFINER table_owner".
I don't remember all the details, but I
Excerpts from Tom Lane's message of lun feb 27 20:54:41 -0300 2012:
> Andres Freund writes:
> > On Tuesday, February 28, 2012 12:30:36 AM Tom Lane wrote:
> >> Ugh ... if that's currently allowed, we definitely need to fix it.
>
> > Btw, whats the danger youre seing?
>
> Well, I'm not sure that
Tom Lane schrieb:
>Andres Freund writes:
>> I refreshed the patch so it works again on current HEAD. Basically
>some
>> trivial fixes and dfd26f9c5f371437f243249025863ea9911aacaa. The
>latter doesn't
>> seem necessary to me after the changes, so I simply ditched it. Am I
>missing
>> somethi
On Mon, Feb 27, 2012 at 02:13:32PM +0200, Heikki Linnakangas wrote:
> On 23.02.2012 18:01, Alvaro Herrera wrote:
>> As far as complexity, yeah, it's a lot more complex now -- no question
>> about that.
>
> How about assigning a new, real, transaction id, to represent the group
> of transaction id
Andres Freund writes:
> I refreshed the patch so it works again on current HEAD. Basically some
> trivial fixes and dfd26f9c5f371437f243249025863ea9911aacaa. The latter
> doesn't
> seem necessary to me after the changes, so I simply ditched it. Am I missing
> something?
No, that was only need
Andres Freund writes:
> On Tuesday, February 28, 2012 12:30:36 AM Tom Lane wrote:
>> Ugh ... if that's currently allowed, we definitely need to fix it.
> Btw, whats the danger youre seing?
Well, I'm not sure that it would actively break anything, but we
definitely meant to disallow the case. Al
Christopher Browne writes:
> On Mon, Feb 27, 2012 at 6:20 PM, Tom Lane wrote:
>> So, whatever the desirability of having them run as table owner,
>> we can't just up and change that.
> I'm inclined to hold to the argument that it Works Properly Now, and
> that we shouldn't break it by changing i
On Tuesday, February 28, 2012 12:30:36 AM Tom Lane wrote:
> Andres Freund writes:
> > Sorry for letting this slide.
> >
> > Is it worth adding this bit to OpenIntoRel? Not sure if there is danger
> > in allowing anyone to create shared tables
> >
> > /* In all cases disallow placing user rel
On Tuesday, February 28, 2012 12:30:36 AM Tom Lane wrote:
> Andres Freund writes:
> > Sorry for letting this slide.
> >
> > Is it worth adding this bit to OpenIntoRel? Not sure if there is danger
> > in allowing anyone to create shared tables
> >
> > /* In all cases disallow placing user rel
On Mon, Feb 27, 2012 at 6:20 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> As far as I can tell, triggers run as the user performing the
>> operation which fires the trigger, not as the owner of the table.
> > Can anyone provide an example of a trigger running as the table
>> owner? Is ther
Andres Freund writes:
> Sorry for letting this slide.
> Is it worth adding this bit to OpenIntoRel? Not sure if there is danger in
> allowing anyone to create shared tables
> /* In all cases disallow placing user relations in pg_global */
> if (tablespaceId == GLOBALTABLESPACE_OID)
On Sunday, December 04, 2011 02:09:08 AM Andres Freund wrote:
> First, does anybody think it would be worth getting rid of the duplication
> from OpenIntoRel (formerly from execMain.c) in regard to DefineRelation()?
> I noticed that there already is some diversion between both. E.g. CREATE
> TABLE
"Kevin Grittner" writes:
> As far as I can tell, triggers run as the user performing the
> operation which fires the trigger, not as the owner of the table.
> Can anyone provide an example of a trigger running as the table
> owner? Is there a bug here? Something for the docs?
A quick look into
Robert Haas writes:
> On Mon, Feb 27, 2012 at 10:17 AM, Hannes Frederic Sowa wrote:
>> As with recent changes to `standard_conforming_strings' the paragraph about
>> backslash escaping in the description of `LIKE' is only confusing. Thus I
>> attached a patch to remove it.
> I think I agree with
> Kevin Grittner wrote:
>> Tom Lane wrote:
>>> By default, a trigger function runs as the table owner, ie it's
>>> implicitly SEC DEF to the table owner.
>>
>> Really? That's certainly what I would *want*, but it's not what
>> I've seen.
>>
>> [self-contained example of that not happening]
C
=?ISO-8859-2?Q?Miroslav_=A9imul=E8=EDk?= writes:
> Is there any way how to force UPDATE to use default value of ID column from
> table a2 when updating rows in this table, without using triggers?
No. The update is expanded using the default expression applicable to
the table that is named in the
On Mon, Feb 27, 2012 at 1:50 PM, David E. Wheeler wrote:
> On Feb 26, 2012, at 4:53 AM, Peter Eisentraut wrote:
>
>>> I also liked Kevin's suggestion of DISCREET
>>
>> That would probably create too much confusion with "discrete".
>
> SECRETE?
BOUND? GAGGED?
--
When confronted by a difficult pr
> Would looking into currently held locks help ? You might get some false
> positive because the transaction may have acquired a lock, but did not do
> any modification. But if you can live with that, it might be worth
> considering.
The locks disappear after corresponding sessions ends or the
tra
Excerpts from Noah Misch's message of jue ene 26 12:00:49 -0300 2012:
>
> On Wed, Jan 25, 2012 at 10:39:56PM -0500, Noah Misch wrote:
> > In any event, the patch needed a rebase, so I've attached it rebased and
> > with
> > that comment edited to reference ri_GenerateQualCollation(), that being
Am 23.02.2012 21:57, schrieb Greg Smith:
On 02/22/2012 05:31 PM, james wrote:
Has anyone considered managing a system like the DragonFLY swapcache for
a DBMS like PostgreSQL?
ie where the admin can assign drives with good random read behaviour
(but perhaps also-ran random write) such as SSDs to
Sorry, I have accidentaly sent incomplet mail.
Here is the rest:
The following sequence of commands will end up with error, because of
duplicate ID in table a2:
insert into a2(data2, data) values(456, 'jkl');
insert into a2(data2, data) values(789, 'mno');
Is there any way how to force
Hi,
I have two tables defined for example like this:
create table a1 (id serial primary key, data text);
create table a2 (id serial primary key, data2 integer) inherits (a1);
The point is, that I want to have two tables with inheritance relation
between them, but each with its own id col
On 02/27/2012 03:39 PM, Tom Lane wrote:
Greg Smith writes:
Here are some Debian/Ubuntu platforms that all run into the other problem:
Ubuntu 9.04, openjade 1.4devel1-19: flow error
Debian Squeeze, openjade 1.4devel1-19 : flow error
I always assumed that the reason this didn't work, but the
Tom Lane writes:
> FWIW, I agree with Thom on this. If we do it as you suggest, I
> confidently predict that it will be less than a year before we seriously
> regret it. Given all the discussion around this, it's borderline insane
> to believe that the set of parameters to be passed to command t
Dimitri Fontaine writes:
> Thom Brown writes:
>> I've got a question regarding the function signatures required for
>> command triggers, and apologies if it's already been discussed to
>> death (I didn't see all the original conversations around this).
>> These differ from regular trigger functio
Hi,
On Friday, February 17, 2012 01:17:27 AM Dan Scales wrote:
> Good point, thanks. From the ext3 source code, it looks like
> ext3_sync_file() does a blkdev_issue_flush(), which issues a flush to the
> block device, whereas simple direct IO does not. So, that would make
> this wal_sync_method
Greg Smith writes:
> Here are some Debian/Ubuntu platforms that all run into the other problem:
> Ubuntu 9.04, openjade 1.4devel1-19: flow error
> Debian Squeeze, openjade 1.4devel1-19 : flow error
> I always assumed that the reason this didn't work, but the Fedoras did,
> was because of a diff
On 02/27/2012 08:08 AM, Robert Haas wrote:
OK, fair point. But I don't think any of us - Greg included - have an
enormously clear idea why turning the background writer off is
improving performance in some cases. I think we need to understand
that better before we start changing things.
Check
Greg Smith writes:
> I just tried building postgres-US.pdf on a RHEL-derived system,
> Scientific Linux 6 using openjade-1.3.2-36.el6. That gave me lots of
> "Overfull hbox" errors, then died like this:
> ! pdfTeX error (ext4): \pdfendlink ended up in different nesting level
> than \pdfstartl
On Feb 27, 2012, at 11:43 AM, Peter Eisentraut wrote:
>> Why not? Not challenging your assertion here, just curious why it’s
>> different.
>
> Because it's not actually a function, it's hardcoded in the grammar to
> call pg_catalog.now().
Ah, I see. Pity.
David
--
Sent via pgsql-hackers maili
On mån, 2012-02-27 at 11:40 -0800, David E. Wheeler wrote:
> On Feb 27, 2012, at 11:39 AM, Peter Eisentraut wrote:
>
> >> I use it for NOW() all the time.
> >
> > But it won't work for current_timestamp.
>
> Why not? Not challenging your assertion here, just curious why it’s different.
Because
On Feb 27, 2012, at 11:39 AM, Peter Eisentraut wrote:
>> I use it for NOW() all the time.
>
> But it won't work for current_timestamp.
Why not? Not challenging your assertion here, just curious why it’s different.
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On mån, 2012-02-27 at 08:48 -0800, David E. Wheeler wrote:
> On Feb 27, 2012, at 4:29 AM, Peter Eisentraut wrote:
>
> >> I create a "mock" schema, add the function to it, and then put it in the
> >> search_path ahead of pg_catalog.
> >
> > That doesn't work for current_timestamp and similar buil
On Monday, February 27, 2012 08:30:31 PM Thom Brown wrote:
> On 27 February 2012 19:19, Dimitri Fontaine wrote:
> > Thom Brown writes:
> >> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
> >> SELECT 1
> >>
> >> This doesn't even get picked up by ANY COMMAND.
> >
> > You
Thom Brown writes:
> CREATE COMMAND TRIGGER test_cmd_trg
> BEFORE CREATE SCHEMA,
> CREATE OPERATOR,
> CREATE COLLATION,
> CREATE CAST
> EXECUTE PROCEDURE my_func();
>
> I couldn't drop it completely unless I specified all of those commands. Why?
Because I couldn't find a nice enough way to
Thom Brown writes:
> I've got a question regarding the function signatures required for
> command triggers, and apologies if it's already been discussed to
> death (I didn't see all the original conversations around this).
> These differ from regular trigger functions which don't require any
> arg
On 27 February 2012 19:19, Dimitri Fontaine wrote:
> Thom Brown writes:
>> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
>> SELECT 1
>>
>> This doesn't even get picked up by ANY COMMAND.
>
> You won't believe it: CTAS is not implemented as a DDL. Andres did
> some work
you're right, changes in cascading tables are not logged.
Ing. Lennin Caro Pérez
Usuario:GNU/LINUX
PHP Developer
PostgreSQL DBA
Oracle DBA
Linux counter id 474393
--- On Mon, 2/27/12, Tatsuo Ishii wrote:
From: Tatsuo Ishii
Subject: Re: [HACKERS] How to know a table has been modifie
Thom Brown writes:
> SELECT * INTO badname FROM goodname;
Again, see Andres' patch about that.
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Thom Brown writes:
> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
> SELECT 1
>
> This doesn't even get picked up by ANY COMMAND.
You won't believe it: CTAS is not implemented as a DDL. Andres did
some work about that and sent a patch that received positive reviews by
b
On Mon, Feb 27, 2012 at 1:08 PM, Robert Haas wrote:
> On Mon, Feb 27, 2012 at 3:50 AM, Simon Riggs wrote:
>> That isn't the case. We have evidence that the current knobs are
>> hugely ineffective in some cases.
>>
>> Turning the bgwriter off is hardly "adjusting a setting", its
>> admitting that
On Mon, February 27, 2012 18:30, Magnus Hagander wrote:
>>
does that work for others, or did we break something globally in it?
>>>
FWIW: I build A4 pdf's for HEAD often (say, weekly), on centos 5; it has always
worked this last
year or so (I did tweak tex (?) parameters, long ago).
I built
2012/2/27 David E. Wheeler :
> On Feb 26, 2012, at 4:53 AM, Peter Eisentraut wrote:
>
>>> I also liked Kevin's suggestion of DISCREET
>>
>> That would probably create too much confusion with "discrete".
>
> SECRETE?
next one
MUTE ?
Regards
Pavel
>
> David
>
>
> --
> Sent via pgsql-hackers mail
On Feb 26, 2012, at 4:53 AM, Peter Eisentraut wrote:
>> I also liked Kevin's suggestion of DISCREET
>
> That would probably create too much confusion with "discrete".
SECRETE?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
On 02/27/2012 12:22 PM, Tom Lane wrote:
FWIW, all the recent reports of this seem to be on Ubuntu or Debian.
Don't know if that means few of us use Fedora or if it means Fedora has
fixed this.
I just tried building postgres-US.pdf on a RHEL-derived system,
Scientific Linux 6 using openjade-1.3
On Mon, Feb 27, 2012 at 9:35 PM, Tatsuo Ishii wrote:
> Are you suggesting log_statement? I don't think it's a solution by
> following reasons:
>
> 1) it's slow to enable that on busy systems
> 2) tables affected by cascading delete/update/drop is not logged in
> PostgreSQL log
>
>
Would looking
On Mon, Feb 27, 2012 at 18:28, Magnus Hagander wrote:
> On Mon, Feb 27, 2012 at 18:22, Tom Lane wrote:
>> Magnus Hagander writes:
>>> On Mon, Feb 27, 2012 at 18:00, Tom Lane wrote:
Something else to keep in mind is that PDF-format docs are not terribly
forgiving of wide tables --- hav
Magnus Hagander writes:
> On Mon, Feb 27, 2012 at 18:22, Tom Lane wrote:
>> FWIW, I built all the back-branch versions in both US and A4 formats
>> last week on Fedora 16. Don't recall trying HEAD though.
> I only tried HEAD. Trying 9.1 now, and I get the same crash there. Can
> you (or someone
On Mon, Feb 27, 2012 at 11:59 AM, Tom Lane wrote:
> Robert Haas writes:
>> I'm almost inclined to think that
>> we should be trying to get rid of heap_open() altogether; there are
>> already plenty of places that assume that opening the relation is as
>> good as opening the heap, so I don't think
On Mon, Feb 27, 2012 at 18:22, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Feb 27, 2012 at 18:00, Tom Lane wrote:
>>> Something else to keep in mind is that PDF-format docs are not terribly
>>> forgiving of wide tables --- have you looked at what these look like in
>>> PDF?
>
>> I have
Magnus Hagander writes:
> On Mon, Feb 27, 2012 at 18:00, Tom Lane wrote:
>> Something else to keep in mind is that PDF-format docs are not terribly
>> forgiving of wide tables --- have you looked at what these look like in
>> PDF?
> I have not, and I can't seem to build them:
> openjade -D . -D
On Mon, Feb 27, 2012 at 18:00, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Feb 27, 2012 at 11:32 AM, Magnus Hagander
>> wrote:
>>> On Mon, Feb 27, 2012 at 14:36, Robert Haas wrote:
Yeah, that's one thing I don't like about what you actually did,
either - it made some of the tabl
Robert Haas writes:
> On Mon, Feb 27, 2012 at 11:32 AM, Magnus Hagander wrote:
>> On Mon, Feb 27, 2012 at 14:36, Robert Haas wrote:
>>> Yeah, that's one thing I don't like about what you actually did,
>>> either - it made some of the tables much wider.
>> Uh, can you give me an example of one?
Robert Haas writes:
> I'm almost inclined to think that
> we should be trying to get rid of heap_open() altogether; there are
> already plenty of places that assume that opening the relation is as
> good as opening the heap, so I don't think there'd be any real loss of
> abstraction.
Or, perhaps,
On Feb 27, 2012, at 4:29 AM, Peter Eisentraut wrote:
>> Sorry, starting at slide 480.
>
> That presentation only goes to slide 394.
Crimony, sorry, this presentation:
http://www.slideshare.net/justatheory/test-drivern-database-development
Note that I put pg_catalog at the end of the search_p
On Feb 27, 2012, at 4:29 AM, Peter Eisentraut wrote:
>> I create a "mock" schema, add the function to it, and then put it in the
>> search_path ahead of pg_catalog.
>
> That doesn't work for current_timestamp and similar built-in functions,
> because they are always mapped to the pg_catalog sche
On Mon, Feb 27, 2012 at 11:32 AM, Magnus Hagander wrote:
> On Mon, Feb 27, 2012 at 14:36, Robert Haas wrote:
>> On Mon, Feb 27, 2012 at 5:22 AM, Magnus Hagander wrote:
>>> The problem with a separate column is that it makes the table very
>>> wide (some of those functions have very long name).
>
On Mon, Feb 27, 2012 at 14:36, Robert Haas wrote:
> On Mon, Feb 27, 2012 at 5:22 AM, Magnus Hagander wrote:
>> The problem with a separate column is that it makes the table very
>> wide (some of those functions have very long name).
>
> Yeah, that's one thing I don't like about what you actually
On Mon, Feb 27, 2012 at 5:45 AM, Marti Raudsepp wrote:
> Here's a tiny cleanup: currently get_tables_to_cluster uses
> heap_open() to open the relation, but then closes it with
> relation_close(). Currently relation_close=heap_close, but it seems
> like good idea to be consistent -- in case these
On Mon, Feb 27, 2012 at 16:20, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Feb 27, 2012 at 04:37, Robert Haas wrote:
>>> Why not change the default? Does anyone really prefer the bare bones
>>> doc output?
>
>> Yes, Peter made a point about preferring that back when we changed the
>> d
Are you suggesting log_statement? I don't think it's a solution by
following reasons:
1) it's slow to enable that on busy systems
2) tables affected by cascading delete/update/drop is not logged in
PostgreSQL log
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
* Tom Lane:
> Hannes Frederic Sowa writes:
>> As with recent changes to `standard_conforming_strings' the paragraph
>> about backslash escaping in the description of `LIKE' is only confusing.
>> Thus I attached a patch to remove it.
>
> The para is still relevant if you don't have standard_conf
yes
2012/2/27 Robert Haas :
> On Sun, Feb 26, 2012 at 10:04 AM, Pavel Stehule
> wrote:
>> Hello
>>
>> I tested creating some larger indexes
>>
>> There was a warning:
>>
>> postgres=# CREATE INDEX idx_resource_name ON resource (name, tid);
>> WARNING: concurrent insert in progress within table
Hannes Frederic Sowa writes:
> As with recent changes to `standard_conforming_strings' the paragraph
> about backslash escaping in the description of `LIKE' is only confusing.
> Thus I attached a patch to remove it.
The para is still relevant if you don't have standard_conforming_strings
on. I
On Mon, Feb 27, 2012 at 10:17 AM, Hannes Frederic Sowa wrote:
> As with recent changes to `standard_conforming_strings' the paragraph about
> backslash escaping in the description of `LIKE' is only confusing. Thus I
> attached a patch to remove it.
I think I agree with removing this paragraph; it
On Sun, Feb 26, 2012 at 10:04 AM, Pavel Stehule wrote:
> Hello
>
> I tested creating some larger indexes
>
> There was a warning:
>
> postgres=# CREATE INDEX idx_resource_name ON resource (name, tid);
> WARNING: concurrent insert in progress within table "resource"
>
> I am sure so there was only
Magnus Hagander writes:
> On Mon, Feb 27, 2012 at 04:37, Robert Haas wrote:
>> Why not change the default? Does anyone really prefer the bare bones
>> doc output?
> Yes, Peter made a point about preferring that back when we changed the
> developer docs to be on the main website (how it got wors
Hi!
As with recent changes to `standard_conforming_strings' the paragraph
about backslash escaping in the description of `LIKE' is only confusing.
Thus I attached a patch to remove it.
Greetings,
Hannes
--
Hannes Sowa
BFK edv-consulting GmbH http://www.bfk.de/
Kri
check the log of postgresql, there you can take the table name and the date of
the modification
Ing. Lennin Caro Pérez
Usuario:GNU/LINUX
PHP Developer
PostgreSQL DBA
Oracle DBA
Linux counter id 474393
--- On Mon, 2/27/12, Tatsuo Ishii wrote:
From: Tatsuo Ishii
Subject: Re: [HACKERS] Ho
On Sun, Feb 26, 2012 at 09:50:04PM -0500, Robert Haas wrote:
> On Sun, Feb 26, 2012 at 10:36 AM, Peter Eisentraut wrote:
> > On lör, 2012-02-25 at 14:21 +0100, Christoph Berg wrote:
> >> Well, I'm trying to invoke the extension's "make check" target at
> >> extension build time. I do have a tempor
On Fri, Feb 24, 2012 at 08:21:05PM +0200, Peter Eisentraut wrote:
> On fre, 2012-02-24 at 17:26 +0100, Sandro Santilli wrote:
> > We don't initdb with PostGIS regression testing framework
> > but I've considered doing it for this specific case and it stroke me
> > that even then we couldn't control
On 2012-02-27 12:49, Asif Rehman wrote:
Hi Yeb Havinga,
I was digging archives to see anyone worked on supporting domain's
over composite type and found your patch, but that was pulled back.
According to commitfest comments it needs some more work...
There were some issues with using the dom
2012/2/27 Alvaro Herrera :
>
> Excerpts from Pavel Stehule's message of lun feb 27 10:41:32 -0300 2012:
>>
>> 2012/2/27 Alvaro Herrera :
>> >
>> > Excerpts from hubert depesz lubaczewski's message of lun feb 27 10:02:57
>> > -0300 2012:
>> >> On Sun, Feb 26, 2012 at 03:04:28PM +0100, Pavel Stehule
Le vendredi 24 février 2012 14:18:44, Florian Weimer a écrit :
> * Alex Shulgin:
> >> It's ugly, but it's standard practice, and seems better than a separate
> >> -d parameter (which sort of defeats the purpose of URIs).
> >
> > Hm, do you see anything what's wrong with "?dbname=other" if you don'
Le mercredi 22 février 2012 20:12:35, Pavel Stehule a écrit :
> 2012/2/22 Kevin Grittner :
> > Pavel Stehule wrote:
> >> usual pattern in our application is
> >>
> >> create table xx1 as select
> >> analyze xx1
> >> create table xx2 as select from xx1,
> >> analyze xx2
> >> create
Excerpts from Pavel Stehule's message of lun feb 27 10:41:32 -0300 2012:
>
> 2012/2/27 Alvaro Herrera :
> >
> > Excerpts from hubert depesz lubaczewski's message of lun feb 27 10:02:57
> > -0300 2012:
> >> On Sun, Feb 26, 2012 at 03:04:28PM +0100, Pavel Stehule wrote:
> >> > Hello
> >> >
> >> >
2012/2/27 Alvaro Herrera :
>
> Excerpts from hubert depesz lubaczewski's message of lun feb 27 10:02:57
> -0300 2012:
>> On Sun, Feb 26, 2012 at 03:04:28PM +0100, Pavel Stehule wrote:
>> > Hello
>> >
>> > I rechecked Depesz's article -
>> > http://www.depesz.com/2011/07/01/waiting-for-9-2-not-vali
On Mon, Feb 27, 2012 at 5:22 AM, Magnus Hagander wrote:
> The problem with a separate column is that it makes the table very
> wide (some of those functions have very long name).
Yeah, that's one thing I don't like about what you actually did,
either - it made some of the tables much wider.
>> s
On Mon, Feb 27, 2012 at 5:35 AM, Miroslav Šimulčík
wrote:
> is there any way to prevent role from modifing values of some columns of NEW
> row in before row triggers? I revoked insert privilege from these columns to
> ensure that only default value can be inserted, but it is still posible to
> mod
Excerpts from hubert depesz lubaczewski's message of lun feb 27 10:02:57 -0300
2012:
> On Sun, Feb 26, 2012 at 03:04:28PM +0100, Pavel Stehule wrote:
> > Hello
> >
> > I rechecked Depesz's article -
> > http://www.depesz.com/2011/07/01/waiting-for-9-2-not-valid-checks/
> >
> > The behave of cur
On Mon, Feb 27, 2012 at 3:50 AM, Simon Riggs wrote:
> That isn't the case. We have evidence that the current knobs are
> hugely ineffective in some cases.
>
> Turning the bgwriter off is hardly "adjusting a setting", its
> admitting that there is no useful setting.
>
> I've suggested changes that
On Sun, Feb 26, 2012 at 03:04:28PM +0100, Pavel Stehule wrote:
> Hello
>
> I rechecked Depesz's article -
> http://www.depesz.com/2011/07/01/waiting-for-9-2-not-valid-checks/
>
> The behave of current HEAD is different than behave described in article.
>
> "alter table a validate constraint a_a_
On tor, 2012-02-23 at 10:55 -0800, David E. Wheeler wrote:
> On Feb 23, 2012, at 10:54 AM, David E. Wheeler wrote:
>
> > I create a "mock" schema, add the function to it, and then put it in the
> > search_path ahead of pg_catalog. See the example starting at slide 48 on
> > http://www.slideshare
On tor, 2012-02-23 at 10:54 -0800, David E. Wheeler wrote:
> I create a "mock" schema, add the function to it, and then put it in the
> search_path ahead of pg_catalog.
That doesn't work for current_timestamp and similar built-in functions,
because they are always mapped to the pg_catalog schema.
On 27 February 2012 06:23, Tom Lane wrote:
> I think that what Peter is on about in
> http://archives.postgresql.org/pgsql-hackers/2012-02/msg01152.php
> is the question of what location to use for the *result* of
> 'literal string'::typename, assuming that the type's input function
> doesn't comp
On 23.02.2012 18:01, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of jue feb 23 12:28:20 -0300 2012:
Alvaro Herrera writes:
Sure. The problem is that we are allowing updated rows to be locked (and
locked rows to be updated). This means that we need to store extended
Xmax informat
1 - 100 of 111 matches
Mail list logo
