Re: [HACKERS] New trigger option of pg_standby

Hi, Thanks for reviewing the patch! On Wed, Apr 22, 2009 at 4:27 AM, Heikki Linnakangas wrote: > Fujii Masao wrote: >> >> Hi, >> >> On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao >> wrote: >>> >>> I'd like to propose another simple idea; pg_standby deletes the >>> trigger file *whenever* the next

Re: [HACKERS] psql with "Function Type" in \df

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Apr 21, 2009 at 01:26:33PM -0400, Bruce Momjian wrote: [...] > I merged the entries into one line: > > \df[antwS+] [PATTERN] list (only agg/normal/trigger/window) functions > > I didn't feel I had room to do [][] like Alvaro suggeste

Re: [HACKERS] [PATCH] unalias of ACL_SELECT_FOR_UPDATE

2009/4/21 KaiGai Kohei : > Robert, currently I could not find semantics breaks in your suggestion. > I plan to update SE- implementation to skip checks during foreign-key > constraints and add a new SE- permission: "reference" which allows > to set up fereign-keys. Sounds good! I hope that works

Re: [HACKERS] WIP: to_char, support for EEEE format

2009/4/21 Brendan Jurd : > On Sat, Apr 11, 2009 at 3:51 AM, Pavel Stehule > wrote: >> So, please, if you can, propose these error messages (with hints)- >> result will be much better. >> > > Hi Pavel, > > I was doing some work on rewording these error messages, and I noticed > that the following

Re: [HACKERS] [PATCH] unalias of ACL_SELECT_FOR_UPDATE

KaiGai Kohei wrote: > Robert Haas wrote: >> On Mon, Apr 20, 2009 at 12:48 PM, Martijn van Oosterhout >> wrote: >>> On Mon, Apr 20, 2009 at 03:48:11PM +0100, Greg Stark wrote: So in this situation -- I suspect, if any SELinux people want to pipe up to tell me whether I'm on the right trac

Re: [HACKERS] [ADMIN] License Issue

Tom Lane wrote: > I wrote: > > Well, we've got AIXen in the buildfarm, shall we rip out those files > > and see what happens? > > On looking closer, the existing special AIX code is all a no-op anyway > if HAVE_DLOPEN is defined, and there is a comment there saying it's been > obsolete since AIX 4

[HACKERS] RelOptInfo cache

Hi, I implemented the Two Phase Optimizer based on an Ioannidis' paper to make some tests. In this source, I used a struct, named treeNode, witch can control a bottom-up RelOptInfo construction cache. This struct has a RelOptInfo, 2 child pointer (treeNode *inner_child, *outer_child) and a pa

Re: [HACKERS] [ADMIN] License Issue

I wrote: > Well, we've got AIXen in the buildfarm, shall we rip out those files > and see what happens? On looking closer, the existing special AIX code is all a no-op anyway if HAVE_DLOPEN is defined, and there is a comment there saying it's been obsolete since AIX 4.3. So I think we're pretty s

Re: [HACKERS] [ADMIN] License Issue

t...@sss.pgh.pa.us (Tom Lane) writes: > Korry Douglas writes: >>> Seems like the easy solution is to rip out the AIX files in your >>> server deployments ... or are you actually intending to support AIX? > >> AIX itself now offers the functions found in src/backend/port/ >> dynloader/aix.c so I t

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

Original-Nachricht > Datum: Tue, 21 Apr 2009 14:53:54 -0400 > Von: Robert Haas > An: steven king > CC: lis...@guedesoft.net, pgsql-hackers@postgresql.org, st...@enterprisedb.com > Betreff: Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax > Of course if you j

Re: [HACKERS] New trigger option of pg_standby

Fujii Masao wrote: Hi, On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao wrote: I'd like to propose another simple idea; pg_standby deletes the trigger file *whenever* the nextWALfile is a timeline history file. A timeline history file is restored at the end of recovery, so it's guaranteed that the

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

Does sql standard defines it ? and another question, what about updating existing partitions, with no need to drop/recreate ? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

On Tue, Apr 21, 2009 at 2:29 PM, steven king wrote: >> Rather than SWITCH CASE ... you probably would >> want to reuse the existing PostgreSQL syntax of CASE WHEN >> ... > > I think - at first we've to ask for the problem we have to solve. > > The syntax it isnt. If we get confused with CASE of

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

Robert Haas writes: > I'm also not sure how skillful the constraint exclusion logic is at > proving theorems when CASE statements are involved. It's not at all, and unlikely to become so. However, I think worrying about that might be focusing on the wrong thing. If this patch expects us to stil

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

Em Ter, 2009-04-21 às 19:33 +0530, Kedar Potdar escreveu: (...) > You can have multiple columns as partition key attributes and values > for these attributes should appear in the order specified. How would be the behavior if the partition keys are foreing key with ON UPDATE CASCADE? I'm thinkin

Re: [HACKERS] [ADMIN] License Issue

Korry Douglas writes: >> Seems like the easy solution is to rip out the AIX files in your >> server deployments ... or are you actually intending to support AIX? > AIX itself now offers the functions found in src/backend/port/ > dynloader/aix.c so I think that file may be obsolete as of (at leas

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

Original-Nachricht > Datum: Tue, 21 Apr 2009 13:36:19 -0400 > Von: Robert Haas > An: steven king > CC: Greg Stark , pgsql-hackers@postgresql.org, > lis...@guedesoft.net > Betreff: Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax > > SWITCH > > CASE TABLE

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

More importantly it makes it a lot harder for the planner to do clever things. Currently having to append two tables means losing the ordering of the records and having to resort. Even if that's fixed it makes it harder to get reasonable estimates for size and distinctness. Ideally partitio

Re: [HACKERS] per db collate syntax

Jaime Casanova wrote: I was trying to create a database and found that we are using LC_COLLATE and LC_CTYPE, why not simply COLLATE and CTYPE? This was discussed recently, and in fact changed from COLLATE/CTYPE to LC_COLLATE/LC_CTYPE. The reason is that LC_COLLATE and LC_CTYPE makes it more c

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

On Tue, Apr 21, 2009 at 12:17 PM, steven king wrote: > the idea is, that this statement does not create a new kind of db-object. > this "CREATE PARTITIONS" statement should be a meta-statement -> "meta" like > the serial type. That was my assumption as well. > with create paritions you can cre

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

>> > The big win that is associated with table partitioning is using >> > constraint exclusion to avoid unnecessary partitions scans. > > there is no reason for not using the 'CASE condition' for constraint > exclusion. There is if you can't rely on the rows to be in the right partition. Allowing

[HACKERS] per db collate syntax

Hi, I was trying to create a database and found that we are using LC_COLLATE and LC_CTYPE, why not simply COLLATE and CTYPE? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mai

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

On Tue, Apr 21, 2009 at 12:35 PM, steven king wrote: > why a partition-key cannot be a complex expression? > > like this: > > SWITCH > CASE TABLE [IN ] > CASE TABLE [IN ] > CASE TABLE [IN ] > DEFAULT [IN ] > > that is generic Rather than SWITCH CASE ... you probably would want to reuse

Re: [HACKERS] psql with "Function Type" in \df

David Fetter wrote: > On Tue, Apr 21, 2009 at 01:04:44PM -0400, Alvaro Herrera wrote: > > David Fetter wrote: > > > > > Oh, and I forgot to send some error-handling and cleanup code per > > > Alvaro. Please find attached. :) > > > > Declarations before code please. > > Fixed patch attached. Ap

Re: [HACKERS] psql with "Function Type" in \df

Alvaro Herrera wrote: > Kevin Grittner wrote: > > Bruce Momjian wrote: > > > > > \df[S+] [PATTERN] list functions > > > \df[antwS+] [PATTERN] list only agg/normal/trigger/window functions > > > > Shouldn't that second line have some curly braces? Like maybe: > > > > \df{antw}[S+] [PAT

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

On Tue, Apr 21, 2009 at 11:50 AM, Csaba Nagy wrote: > On Tue, 2009-04-21 at 11:43 -0400, Robert Haas wrote: >> This doesn't sound like a very good idea, because the planner cannot >> then rely on the overflow table not containing tuples that ought to be >> within some other partition. >> >> The bi

Re: [HACKERS] [ADMIN] License Issue

Korry Douglas wrote: >>> I am part of an organization that is beginning to write commercial >>> applications for various Portals (Liferay, etc.). We would like to >>> be >>> able to deploy PostGresQL as the lightweight database for the Portal >>> to >>> connect to. Our request for approval to

Re: [HACKERS] [ADMIN] License Issue

I am part of an organization that is beginning to write commercial applications for various Portals (Liferay, etc.). We would like to be able to deploy PostGresQL as the lightweight database for the Portal to connect to. Our request for approval to our Legal Department has stalled due to th

Re: [HACKERS] psql with "Function Type" in \df

On Tue, Apr 21, 2009 at 01:04:44PM -0400, Alvaro Herrera wrote: > David Fetter wrote: > > > Oh, and I forgot to send some error-handling and cleanup code per > > Alvaro. Please find attached. :) > > Declarations before code please. Fixed patch attached. Cheers, David. -- David Fetter http://

Re: [HACKERS] psql with "Function Type" in \df

"Kevin Grittner" writes: > Bruce Momjian wrote: >> The problem is I don't see curly braces used anywhere in \? > I see it in 8.3: > : \d{t|i|s|v|S} [PATTERN] (add "+" for more detail) > :list tables/indexes/sequences/views/system tables Yeah. The only reason that \d[tisv] do

Re: [HACKERS] psql with "Function Type" in \df

David Fetter wrote: > Oh, and I forgot to send some error-handling and cleanup code per > Alvaro. Please find attached. :) Declarations before code please. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via

Re: [HACKERS] New trigger option of pg_standby

On Tue, Apr 21, 2009 at 12:25:50PM +0100, Simon Riggs wrote: > > No, removing trigger file as soon as a non-existant file is > > requested still seems simpler than deleting it whenever a timeline > > history file is requested. > > If you do this, then you would have to change the procedure written

Re: [HACKERS] psql with "Function Type" in \df

On Tue, Apr 21, 2009 at 09:33:26AM -0700, David Fetter wrote: > On Tue, Apr 21, 2009 at 09:26:13AM -0700, Joshua D. Drake wrote: > > On Tue, 2009-04-21 at 12:19 -0400, Alvaro Herrera wrote: > > > > > I suggested this to Bruce over IM: > > > > > > \df[antw][S+] list [only agg/normal/trigger/wi

Re: [HACKERS] psql with "Function Type" in \df

Bruce Momjian wrote: > The problem is I don't see curly braces used anywhere in \? I see it in 8.3: : \d{t|i|s|v|S} [PATTERN] (add "+" for more detail) :list tables/indexes/sequences/views/system tables and: : \pset NAME [VALUE] :set table output option :

Re: [HACKERS] WIP: to_char, support for EEEE format

On Sat, Apr 11, 2009 at 3:51 AM, Pavel Stehule wrote: > So, please, if you can, propose these error messages (with hints)- > result will be much better. > Hi Pavel, I was doing some work on rewording these error messages, and I noticed that the following code segment occurs identically in four d

Re: [HACKERS] psql with "Function Type" in \df

Alvaro Herrera wrote: > \df[antw][S+] list [only agg/normal/trigger/window] functions > > (one line only, removing the second redundant line). This seems > clea[nr]er to me. Bruce says it would confuse users. That's clear to me, anyway (if you include PATTERN). I'd be fine with it or

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

> SWITCH > CASE TABLE [IN ] > CASE TABLE [IN ] > CASE TABLE [IN ] > DEFAULT [IN ] some examples: CREATE TABLE ttt ( id integer, txt varchar ) SWITCH id % 3 CASE 0 TABLE [IN ] CASE 1 TABLE [IN ] CASE 2 TABLE [IN ] DEFAULT [IN ] or SWITCH lower(txt) CASE 'hello' TABLE [IN ] CASE

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

Original-Nachricht > Datum: Tue, 21 Apr 2009 16:37:15 +0100 > Von: Greg Stark > An: vac...@quantentunnel.de > CC: "Dickson S. Guedes" , pgsql-hackers@postgresql.org > Betreff: Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax > On Tue, Apr 21, 2009 at 4:13 PM,

Re: [HACKERS] psql with "Function Type" in \df

On Tue, Apr 21, 2009 at 09:26:13AM -0700, Joshua D. Drake wrote: > On Tue, 2009-04-21 at 12:19 -0400, Alvaro Herrera wrote: > > > I suggested this to Bruce over IM: > > > > \df[antw][S+] list [only agg/normal/trigger/window] functions > > > > (one line only, removing the second redundant lin

Re: [HACKERS] psql with "Function Type" in \df

Kevin Grittner wrote: > Bruce Momjian wrote: > > > \df[S+] [PATTERN] list functions > > \df[antwS+] [PATTERN] list only agg/normal/trigger/window functions > > Shouldn't that second line have some curly braces? Like maybe: > > \df{antw}[S+] [PATTERN] list only agg/normal/trigger/wind

Re: [HACKERS] psql with "Function Type" in \df

On Tue, 2009-04-21 at 12:19 -0400, Alvaro Herrera wrote: > I suggested this to Bruce over IM: > > \df[antw][S+] list [only agg/normal/trigger/window] functions > > (one line only, removing the second redundant line). This seems > clea[nr]er to me. Bruce says it would confuse users. But re

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

Original-Nachricht > Datum: Tue, 21 Apr 2009 17:50:02 +0200 > Von: Csaba Nagy > An: Robert Haas > CC: Kedar Potdar , Greg Stark > , pgsql-hackers@postgresql.org > Betreff: Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax > > The big win that is associated

Re: [HACKERS] psql with "Function Type" in \df

Kevin Grittner wrote: > Bruce Momjian wrote: > > > \df[S+] [PATTERN] list functions > > \df[antwS+] [PATTERN] list only agg/normal/trigger/window functions > > Shouldn't that second line have some curly braces? Like maybe: > > \df{antw}[S+] [PATTERN] list only agg/normal/trigger/wind

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

On Tue, 2009-04-21 at 11:43 -0400, Robert Haas wrote: > This doesn't sound like a very good idea, because the planner cannot > then rely on the overflow table not containing tuples that ought to be > within some other partition. > > The big win that is associated with table partitioning is using >

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

the idea is, that this statement does not create a new kind of db-object. this "CREATE PARTITIONS" statement should be a meta-statement -> "meta" like the serial type. with create paritions you can create all defined tables (maybe by inheritin from ) at once. but you're right - why this state

Re: [HACKERS] [ADMIN] License Issue

That would be ideal, and it may come to that. Our Legal department gets a little 'sticky' when we try to modify Open Source Software, so I'd like to avoid that if I can. Randy -Original Message- From: Alvaro Herrera [ma

Re: [HACKERS] psql with "Function Type" in \df

Bruce Momjian wrote: > \df[S+] [PATTERN] list functions > \df[antwS+] [PATTERN] list only agg/normal/trigger/window functions Shouldn't that second line have some curly braces? Like maybe: \df{antw}[S+] [PATTERN] list only agg/normal/trigger/window functions Technically, it should

Re: [HACKERS] [ADMIN] License Issue

May, Randy wrote: > PostGresQL Admin, > > > > I am part of an organization that is beginning to write commercial > applications for various Portals (Liferay, etc.). We would like to be > able to deploy PostGresQL as the lightweight database for the Portal to > connect to. Our request for appr

Re: [HACKERS] psql with "Function Type" in \df

David Fetter wrote: > On Wed, Apr 15, 2009 at 08:54:10PM -0400, Alvaro Herrera wrote: > > David Fetter wrote: > > > > > > > I think it's good to have them translatable. As for using "aggregate" > > > > > instead of "agg" I don't think it's that great an idea. If you need > > > > > to > > > > >

Re: [HACKERS] [ADMIN] License Issue

May, Randy wrote: > PostGresQL Admin, > > > > I am part of an organization that is beginning to write commercial > applications for various Portals (Liferay, etc.). We would like to be > able to deploy PostGresQL as the lightweight database for the Portal to > connect to. Our request for appr

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

On Tue, Apr 21, 2009 at 9:38 AM, Kedar Potdar wrote: > Currently, such records are left in the overflow partition and its > responsibility > of user to insert them into partitioned-table which will then re-direct > those to > appropriate partitions. This doesn't sound like a very good idea, becau

Re: [HACKERS] New trigger option of pg_standby

Andreas Pflug wrote: I'm a little confused. After pg_standby returned non-zero as indication for end-of-recovery, the startup process shouldn't request another file from pg_standby, right? Non-zero return value from restore_command doesn't mean end-of-recovery, it means file-not-found. The ser

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

On Tue, Apr 21, 2009 at 11:13 AM, wrote: > oh sorry .. > > but what I miss in this discussion - where we can define tablespace? > > CREATE PARTITIONS ON ( > > CASE WHEN THEN emp_xxx [IN ], > CASE WHEN THEN emp_yyy [IN ], > CASE WHEN emp_zzz [IN ], > ELSE emp_default [IN ] > ) Oh blech. That

Re: [HACKERS] [ADMIN] License Issue

On Tue, 2009-04-21 at 11:13 -0400, May, Randy wrote: > PostGresQL Admin, > This is more of a hackers discussion. I am forwarding there. -Hackers, Do we have a history on this file? Joshua D. Drake > > > I am part of an organization that is beginning to write commercial > applications for

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

On Tue, Apr 21, 2009 at 4:13 PM, wrote: > oh sorry .. > > but what I miss in this discussion - where we can define tablespace? > > CREATE PARTITIONS ON ( > > CASE WHEN THEN emp_xxx [IN ], One thing you should realize is that the actual details of the syntax will be knocked around and redefined

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

oh sorry .. but what I miss in this discussion - where we can define tablespace? CREATE PARTITIONS ON ( CASE WHEN THEN emp_xxx [IN ], CASE WHEN THEN emp_yyy [IN ], CASE WHEN emp_zzz [IN ], ELSE emp_default [IN ] ) Original-Nachricht > Datum: Tue, 21 Apr 2009 11:11:54 -030

Re: [HACKERS] New trigger option of pg_standby

On Tue, 2009-04-21 at 15:55 +0300, Heikki Linnakangas wrote: > Fujii Masao wrote: > > On Tue, Apr 21, 2009 at 8:28 PM, Heikki Linnakangas > > wrote: > >> Simon Riggs wrote: > >>> What you propose is *better* than raw pg_standby is now, but still not > >>> enough in all cases, as I think you know.

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

> > >> > (...) > >> > PARTITION BY RANGE (emp_id) > >> > ( > >> > emp_500 (START 1 END 500), > >> > emp_1500 (START 500 END 1500), > >> > emp_4000 (START 1520 END 4000) > >> > ); > >> > >> What if I need more columns to set the partitions? > > > > > > You can do so by using command like this, > > >

Re: [HACKERS] New trigger option of pg_standby

Fujii Masao wrote: > Hi, > > On Tue, Apr 21, 2009 at 8:28 PM, Heikki Linnakangas > wrote: > >> Simon Riggs wrote: >> >>> If you do this, then you would have to change the procedure written into >>> the 8.3 docs also. Docs aren't backpatchable. >>> >>> What you propose is *better* than raw

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

2009/4/21 Kedar Potdar : > > > 2009/4/21 Dickson S. Guedes >> >> Em Ter, 2009-04-21 às 17:20 +0530, Kedar Potdar escreveu: >> > Hi , >> > >> > We are working on a patch to automate partitioning in PostgreSQL. >> >> Nice. ":) >> >> > For Range partitions, we have proposed the syntax which is as >>

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

Vacuum, I guess you forgot to reply-to-all. ":) Em Ter, 2009-04-21 às 16:05 +0200, vac...@quantentunnel.de escreveu: > why not partitions by "conditions"? > > you can do that in similar way how "case when then " works .. > > CREATE PARTITIONS ON > SWITCH > CASE THEN , > CASE THEN ,

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

2009/4/21 Dickson S. Guedes > Em Ter, 2009-04-21 às 17:20 +0530, Kedar Potdar escreveu: > > Hi , > > > > We are working on a patch to automate partitioning in PostgreSQL. > > Nice. ":) > > > For Range partitions, we have proposed the syntax which is as > > follows > > > > (...) > > PARTITION BY R

Re: [HACKERS] 8.4 semi-join slows down query performance (EXISTS)

vac...@quantentunnel.de wrote: > Hello folk, > > I migrate a pg 8.3 database to a pg 8.4 backend for testing. All works > fine except changes or new features of the planner. > > There are two tables. The first (A) stores "data" - second table (B) > holds (forinstance) "structure" information and

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

Em Ter, 2009-04-21 às 17:20 +0530, Kedar Potdar escreveu: > Hi , > > We are working on a patch to automate partitioning in PostgreSQL. Nice. ":) > For Range partitions, we have proposed the syntax which is as > follows > > (...) > PARTITION BY RANGE (emp_id) > ( > emp_500 (START 1 END 500),

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

Hi Greg, Thanks for your response. Currently, such records are left in the overflow partition and its responsibility of user to insert them into partitioned-table which will then re-direct those to appropriate partitions. Regards, -- Kedar. On Tue, Apr 21, 2009 at 5:29 PM, Greg Stark wrote: >

Re: [HACKERS] New trigger option of pg_standby

Fujii Masao wrote: On Tue, Apr 21, 2009 at 8:28 PM, Heikki Linnakangas wrote: Simon Riggs wrote: What you propose is *better* than raw pg_standby is now, but still not enough in all cases, as I think you know. No, I don't. What is the case where it doesn't work? It's the case which I descri

Re: [HACKERS] 8.4 semi-join slows down query performance (EXISTS)

I hope this will treat as a "planner-bug". I think the problem is tricky but not hard to solve. Original-Nachricht > Datum: Tue, 21 Apr 2009 13:53:01 +0200 > Von: Guillaume Smet > An: vac...@quantentunnel.de > CC: pgsql-hackers@postgresql.org > Betreff: Re: [HACKERS] 8.4 semi-j

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

On Tue, Apr 21, 2009 at 12:50 PM, Kedar Potdar wrote: > I want to seek general opinion from the community on preferences between > user-friendly ‘Oracle’ syntax, and a more generic syntax that allows ‘gaps’ > in partition ranges? What happens to records in the overflow table when you add a new p

Re: [HACKERS] 8.4 semi-join slows down query performance (EXISTS)

On Tue, Apr 21, 2009 at 11:38 AM, wrote: > I've queries returning tupels of A, with a (sub-)selected constant-expression > that indicates whether a referenced tupel exists in B or not. For this issue > the EXISTS clause is used. > > In past (8.3) the planner resolves this into index-scans using

[HACKERS] Automating Partitions in PostgreSQL - Query on syntax

Hi , We are working on a patchto automate partitioning in PostgreSQL. For Range partitions, we have proposed the syntax which is as follows – *CREATE TABLE emp (* *emp_id int not null primary key,* *desig

Re: [HACKERS] New trigger option of pg_standby

Hi, On Tue, Apr 21, 2009 at 8:28 PM, Heikki Linnakangas wrote: > Simon Riggs wrote: >> >> If you do this, then you would have to change the procedure written into >> the 8.3 docs also. Docs aren't backpatchable. >> >> What you propose is *better* than raw pg_standby is now, but still not >> enoug

Re: [HACKERS] Extend PL/pgSQL

On Tue, Apr 21, 2009 at 3:09 AM, Demise Garrouste wrote: > Hello, > > I am in workplacement in a company and I have to make a migration from one > database to PostGreSQL. Nevertheless, the migration is not possible, because > I don't have the GOTO instruction. I know this is a bad practice, howeve

Re: [HACKERS] New trigger option of pg_standby

On Tue, 2009-04-21 at 14:28 +0300, Heikki Linnakangas wrote: > > Simple isn't the requirement here, is it? > > Simplicity is always a virtue, because it leads to maintainability. "Simple enough" is a virtue. Less than that is not... -- Simon Riggs www.2ndQuadrant.com PostgreSQL T

Re: [HACKERS] New trigger option of pg_standby

Simon Riggs wrote: If you do this, then you would have to change the procedure written into the 8.3 docs also. Docs aren't backpatchable. What you propose is *better* than raw pg_standby is now, but still not enough in all cases, as I think you know. No, I don't. What is the case where it does

Re: [HACKERS] New trigger option of pg_standby

On Tue, 2009-04-21 at 14:17 +0300, Heikki Linnakangas wrote: > Simon Riggs wrote: > > On Mon, 2009-04-20 at 17:47 +0300, Heikki Linnakangas wrote: > > > >> At the end of archive recovery, the server always probes for the > >> timeline by requesting history files until it fails to find one. That

Re: [HACKERS] New trigger option of pg_standby

Simon Riggs wrote: On Mon, 2009-04-20 at 17:47 +0300, Heikki Linnakangas wrote: At the end of archive recovery, the server always probes for the timeline by requesting history files until it fails to find one. That probing should remove the trigger file if it hasn't been removed by then. It's

Re: [HACKERS] New trigger option of pg_standby

On Mon, 2009-04-20 at 17:47 +0300, Heikki Linnakangas wrote: > At the end of archive recovery, the server always probes for the > timeline by requesting history files until it fails to find one. That > probing should remove the trigger file if it hasn't been removed by > then. It's a bit coinc

Re: [HACKERS] [PATCH] Add a test for pg_get_functiondef()

At 2009-04-13 10:40:41 -0400, t...@sss.pgh.pa.us wrote: > > Abhijit Menon-Sen writes: > > [ a test whose purpose he didn't bother to describe ] I'm sorry about that. > What is the value of this? It seems far more likely to cause > maintenance pain than to catch anything interesting. While I was

Re: [HACKERS] Extend PL/pgSQL

Hello 2009/4/21 Laurent Laborde : > On Tue, Apr 21, 2009 at 9:09 AM, Demise Garrouste wrote: >> Hello, >> >> I am in workplacement in a company and I have to make a migration from one >> database to PostGreSQL. Nevertheless, the migration is not possible, because >> I don't have the GOTO instruct

Re: [HACKERS] Extend PL/pgSQL

On Tue, Apr 21, 2009 at 9:09 AM, Demise Garrouste wrote: > Hello, > > I am in workplacement in a company and I have to make a migration from one > database to PostGreSQL. Nevertheless, the migration is not possible, because > I don't have the GOTO instruction. I know this is a bad practice, howeve

[HACKERS] Extend PL/pgSQL

Hello, I am in workplacement in a company and I have to make a migration from one database to PostGreSQL. Nevertheless, the migration is not possible, because I don't have the GOTO instruction. I know this is a bad practice, however, I wanted to know if it's possible to implement this feature. If i

Re: [HACKERS] Why isn't stats_temp_directory automatically created?

Hi, On Mon, Apr 20, 2009 at 1:29 AM, Magnus Hagander wrote: > Sorry about the very late response - I've been out of the country and > generally busy. Thanks for taking the time to comment! >> On Wed, Apr 15, 2009 at 5:37 PM, Magnus Hagander wrote: >>> This does not take into account the effect