Re: [HACKERS] Maintenance announcement for alderaan/barzan/minshara.postgresql.org

2009-03-04 Thread Stefan Kaltenbrunner
Stefan Kaltenbrunner wrote: there will be planned maintenance tomorrow(4 March 2009) from 09:00 to 10:00 CET for the following servers and corresponding services: barzan.postgresql.org - affecting: * xindi.postgresql.org (wiki.postgresql.org) * rakhar.postgresql.org (planet.postgresql.org)

Re: [pgsql-www] [HACKERS] Maintenance announcement for alderaan/barzan/minshara.postgresql.org

2009-03-04 Thread Magnus Hagander
Stefan Kaltenbrunner wrote: Stefan Kaltenbrunner wrote: there will be planned maintenance tomorrow(4 March 2009) from 09:00 to 10:00 CET for the following servers and corresponding services: barzan.postgresql.org - affecting: * xindi.postgresql.org (wiki.postgresql.org) *

Re: [HACKERS] Make SIGHUP less painful if pg_hba.conf is not readable

2009-03-04 Thread Magnus Hagander
Selena Deckelmann wrote: Tom Lane wrote: Selena Deckelmann sel...@endpoint.com writes: From the comment in hba.c, it appears that the desired behavior is to have the system ignore the failure, I'm not sure how you could possibly read that comment that way. Right. Sorry, poor choice of

Re: [HACKERS] Immediate shutdown and system(3)

2009-03-04 Thread Heikki Linnakangas
Per discussion, here's a patch for pg_standby in REL8_3_STABLE. The signal handling is changed so that SIGQUIT no longer triggers failover, but immediately kills pg_standby, triggering FATAL death of the startup process too. That's what you want with immediate shutdown. SIGUSR1 is now

Re: [HACKERS] Make SIGHUP less painful if pg_hba.conf is not readable

2009-03-04 Thread Magnus Hagander
Joshua Tolley wrote: On Wed, Mar 04, 2009 at 09:43:55AM +0100, Magnus Hagander wrote: So. I've updated the comment, and applied your patch. Thanks! What would it take to get it applied to a few earlier versions as well? I guess you maintaining your own fork? ;-) Simply put, earlier

[HACKERS] Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite

2009-03-04 Thread Guillaume Smet
On Wed, Mar 4, 2009 at 11:06 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: While this isn't a bug, it's a reasonable feature request. I've added this to the TODO page: http://wiki.postgresql.org/wiki/Todo#ALTER Patches are welcome. I remember someone proposed a patch for

[HACKERS] Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite

2009-03-04 Thread Guillaume Smet
On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut pete...@gmx.net wrote: The question is how you want to implement this in a data type independent fashion.  You can't assume that increasing the typmod is a noop for all data types. Sure. See my previous answer on -hackers (I don't think this

Re: [HACKERS] Immediate shutdown and system(3)

2009-03-04 Thread Heikki Linnakangas
Fujii Masao wrote: Hi, On Mon, Mar 2, 2009 at 4:59 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Fujii Masao wrote: On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: I'm leaning towards option 3, but I wonder if anyone sees a

Re: [HACKERS] Regclass and quoted table names

2009-03-04 Thread Emmanuel Cecchet
Tom Lane wrote: Emmanuel Cecchet m...@asterdata.com writes: It looks like the behavior of regclass is not consistent when table names are quoted. The name is returned without the quotes if the name is lower case with eventual trailing numbers, otherwise it is returned with quotes.

Re: [HACKERS] Regclass and quoted table names

2009-03-04 Thread Greg Stark
On Wed, Mar 4, 2009 at 12:34 PM, Emmanuel Cecchet m...@asterdata.com wrote: This is problematic in situations where the output of the cast is involved in some later join which returns incorrect results because of the extra double quotes surrounding the table name. Is there a way to override

Re: [HACKERS] SQL/MED compatible connection manager

2009-03-04 Thread Peter Eisentraut
Martin Pihlak wrote: Proposal attached. This adds two C functions: List *GetForeignConnectionOptions(Oid serverid, Oid userid); char *GetForeignConnectionString(Oid serverid, Oid userid); One for obtaining all of the connection related options as a list, and another for transforming these

Re: [HACKERS] SIGHUP during recovery

2009-03-04 Thread Heikki Linnakangas
Fujii Masao wrote: Currently, the startup process ignores SIGHUP. The attached patch allows the startup process to re-read config file: when SIGHUP arrives, the startup process also receives the signal from postmaster and reload the settings in main redo apply loop. Obviously, this is useful to

Re: [HACKERS] Make SIGHUP less painful if pg_hba.conf is not readable

2009-03-04 Thread Joshua Tolley
On Wed, Mar 04, 2009 at 10:28:42AM +0100, Magnus Hagander wrote: Joshua Tolley wrote: On Wed, Mar 04, 2009 at 09:43:55AM +0100, Magnus Hagander wrote: So. I've updated the comment, and applied your patch. Thanks! What would it take to get it applied to a few earlier versions as well?

[HACKERS] SYNONYMs revisited

2009-03-04 Thread Joshua Tolley
Way back in this thread[1] one of the arguments against allowing some version of CREATE SYNONYM was that we couldn't create a synonym for an object in a remote database. Will the SQL/MED work make this sort of thing a possibility? I realize since it's not standard anyway, there's still a

Re: [HACKERS] Regclass and quoted table names

2009-03-04 Thread Tom Lane
Greg Stark st...@enterprisedb.com writes: On Wed, Mar 4, 2009 at 12:34 PM, Emmanuel Cecchet m...@asterdata.com wrote: This is problematic in situations where the output of the cast is involved in some later join which returns incorrect results because of the extra double quotes surrounding the

Re: [HACKERS] building pg_dump doesn't work

2009-03-04 Thread Alvaro Herrera
Alvaro Herrera wrote: Hmm, I had thought that pg_dump only wanted the header file, not the keywords.o object file. I now see that I was wrong. I agree that your proposed solution is a lot better. I'll see about it. Here it is. The #ifdef parts seem a bit ugly, but I'm not sure how can

Re: [HACKERS] building pg_dump doesn't work

2009-03-04 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Perhaps this could be made less ugly by only having the ScanKeywords array in the .c file, and #including that into other .c files in src/backend/parser, ecpg and pg_dump. What I'd suggest is something similar to the design of

Re: [HACKERS] building pg_dump doesn't work

2009-03-04 Thread Heikki Linnakangas
Alvaro Herrera wrote: Alvaro Herrera wrote: Hmm, I had thought that pg_dump only wanted the header file, not the keywords.o object file. I now see that I was wrong. I agree that your proposed solution is a lot better. I'll see about it. Here it is. The #ifdef parts seem a bit ugly, but

Re: [HACKERS] building pg_dump doesn't work

2009-03-04 Thread Alvaro Herrera
Tom Lane wrote: Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Perhaps this could be made less ugly by only having the ScanKeywords array in the .c file, and #including that into other .c files in src/backend/parser, ecpg and pg_dump. What I'd suggest is something

Re: [HACKERS] SYNONYMs revisited

2009-03-04 Thread Hans-Jürgen Schönig
Joshua Tolley wrote: Way back in this thread[1] one of the arguments against allowing some version of CREATE SYNONYM was that we couldn't create a synonym for an object in a remote database. Will the SQL/MED work make this sort of thing a possibility? I realize since it's not standard anyway,

Re: [HACKERS] building pg_dump doesn't work

2009-03-04 Thread Alvaro Herrera
Heikki Linnakangas wrote: Alvaro Herrera wrote: /* + * We don't want to include the gram.h file on frontend builds, except ECPG, so + * leave out the second struct member in that case. + */ + #if !defined FRONTEND || defined ECPG_COMPILE + #define PG_KEYWORD(a,b,c) {a,b,c} + #else

Re: [HACKERS] building pg_dump doesn't work

2009-03-04 Thread Alvaro Herrera
Alvaro Herrera wrote: Tom Lane wrote: What I'd suggest is something similar to the design of the errcodes.h header: create a header file containing just the list of PG_KEYWORD macro calls, and have the different users #include it after defining that macro appropriately. Having .c files

Re: [HACKERS] building pg_dump doesn't work

2009-03-04 Thread Alvaro Herrera
Alvaro Herrera wrote: Alvaro Herrera wrote: Tom Lane wrote: What I'd suggest is something similar to the design of the errcodes.h header: create a header file containing just the list of PG_KEYWORD macro calls, and have the different users #include it after defining that macro

Re: [HACKERS] SQL/MED compatible connection manager

2009-03-04 Thread Tom Lane
Peter Eisentraut pete...@gmx.net writes: I think the proper way to handle it might be to introduce a new privilege type -- call it SELECT if you like -- that determines specifically whether you can *see* the options of a foreign-data wrapper, foreign server, or user mapping, respectively.

Re: [HACKERS] building pg_dump doesn't work

2009-03-04 Thread Tom Lane
Alvaro Herrera alvhe...@commandprompt.com writes: Seems doable. Attached. The TWO_MEMBER_SCANKEYWORD business seems a bit dangerous --- if the header file is read without having #defined that correctly, bad things will happen. It might be better to leave that out, always define the struct the

Re: [HACKERS] SQL/MED compatible connection manager

2009-03-04 Thread David Fetter
On Wed, Mar 04, 2009 at 03:26:36PM +0200, Peter Eisentraut wrote: Martin Pihlak wrote: Proposal attached. This adds two C functions: List *GetForeignConnectionOptions(Oid serverid, Oid userid); char *GetForeignConnectionString(Oid serverid, Oid userid); One for obtaining all of the

Re: [HACKERS] SYNONYMs revisited

2009-03-04 Thread Joshua Tolley
On Wed, Mar 04, 2009 at 10:14:41AM -0500, Jonah H. Harris wrote: SQL/MED does support foreign tables, which are basically synonyms for remote tables. Other than that, it has no real similarity to synonym behavior for other database objects such as views, functions, or local

Re: [HACKERS] SYNONYMs revisited

2009-03-04 Thread Tom Lane
Joshua Tolley eggyk...@gmail.com writes: I didn't mean to suggest that SQL/MED on its own could be used to make SYNONYMs, but rather that given SQL/MED, perhaps we could reconsider some sort of CREATE SYNONYM functionality to go along with it. A major argument against CREATE SYNONYM in the

[HACKERS] Is there an official log reader for PostgreSQL?

2009-03-04 Thread Dann Corbit
I am interested in doing a near real time transaction processor. If there is a place to find the specification for the log reader, I would be keen to know it. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] SYNONYMs revisited

2009-03-04 Thread Peter Eisentraut
On Wednesday 04 March 2009 16:34:54 Joshua Tolley wrote: Way back in this thread[1] one of the arguments against allowing some version of CREATE SYNONYM was that we couldn't create a synonym for an object in a remote database. Will the SQL/MED work make this sort of thing a possibility? The

Re: [HACKERS] Review: B-Tree emulation for GIN

2009-03-04 Thread Heikki Linnakangas
The GIN_EXTRACT_VALUE macro returns a pointer to a static 'entries' variable. That doesn't seem safe. Is it really never possible to have to two GIN searches in a plan, both calling and using the value returned by extractValue simultaneously? In any case that seems like a pretty weak

Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1668)

2009-03-04 Thread Heikki Linnakangas
Ok, I've taken a quick look at this too. My first impression is that this is actually not a very big patch. Much much smaller than I was afraid of. It seems that dropping the row-level security and the other change you've already done have helped a great deal. My first question is, why does

Re: [HACKERS] Is there an official log reader for PostgreSQL?

2009-03-04 Thread Dimitri Fontaine
Hi, Le 4 mars 09 à 21:17, Dann Corbit a écrit : I am interested in doing a near real time transaction processor. If there is a place to find the specification for the log reader, I would be keen to know it. Have you read about PGQ yet? Some links include:

Re: [HACKERS] Regclass and quoted table names

2009-03-04 Thread Emmanuel Cecchet
marcin mank wrote: Use plain oids or regclass values, not a text column, if you are trying to store table identities. wouldn`t oids change on dump/reload? I don't know. I'd also be interested to know if there is a difference if we use pg_restore with a binary format or sql dump, or if

Re: [HACKERS] Is there an official log reader for PostgreSQL?

2009-03-04 Thread Dann Corbit
-Original Message- From: Dimitri Fontaine [mailto:dfonta...@hi-media.com] Sent: Wednesday, March 04, 2009 12:28 PM To: Dann Corbit Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Is there an official log reader for PostgreSQL? Hi, Le 4 mars 09 à 21:17, Dann Corbit a

[HACKERS] Prepping to break every past release...

2009-03-04 Thread Joshua D. Drake
Hello, Something that continues to grind my teeth about our software is that we are horribly inconsistent with our system catalogs. Now I am fully and 100% aware that changing this will break things in user land but I want to do it anyway. In order to do that I believe we need to come up with a

Re: [HACKERS] Regclass and quoted table names

2009-03-04 Thread marcin mank
Use plain oids or regclass values, not a text column, if you are trying to store table identities. wouldn`t oids change on dump/reload? Greetings Marcin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] SYNONYMs revisited

2009-03-04 Thread Joshua Tolley
On Wed, Mar 04, 2009 at 03:15:23PM -0500, Tom Lane wrote: Joshua Tolley eggyk...@gmail.com writes: I didn't mean to suggest that SQL/MED on its own could be used to make SYNONYMs, but rather that given SQL/MED, perhaps we could reconsider some sort of CREATE SYNONYM functionality to go

[HACKERS] cbrt() broken in AIX

2009-03-04 Thread André Volpato
I´m trying to install postgres 8.3.6 at AIX 5.3, and I got a declaration error that I presume its related to this [1] thread. Here´s some info: - Bladecenter IBM JS22 - PowerPC_POWER6 quad 4GHZ 64 bits - AIX 5.3.0 - Postgresql 8.3.6 - gcc version 4.2.0 - GNU Make 3.80 First I tryed to

Re: [HACKERS] cbrt() broken in AIX

2009-03-04 Thread Thomas Pundt
Hi, André Volpato schrieb: I´m trying to install postgres 8.3.6 at AIX 5.3, and I got a declaration error that I presume its related to this [1] thread. [...] After some googling, I find Bruce´s path back on 7.4, that removed my_cbrt trick. So, I changed float.c to the old code (the whole

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Andrew Dunstan
Joshua D. Drake wrote: Hello, Something that continues to grind my teeth about our software is that we are horribly inconsistent with our system catalogs. Now I am fully and 100% aware that changing this will break things in user land but I want to do it anyway. In order to do that I believe

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Dave Page
On Wed, Mar 4, 2009 at 8:32 PM, Joshua D. Drake j...@commandprompt.com wrote: Hello, Something that continues to grind my teeth about our software is that we are horribly inconsistent with our system catalogs. Now I am fully and 100% aware that changing this will break things in user land but

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Joshua D. Drake
On Wed, 2009-03-04 at 15:50 -0500, Andrew Dunstan wrote: It seems to me that the best method would be to follow the information_schema naming conventions as information_schema is standard compliant (right?). Thoughts? What would be the benefit? Apart from satisfying a passion

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Joshua D. Drake
On Wed, 2009-03-04 at 21:01 +, Dave Page wrote: On Wed, Mar 4, 2009 at 8:32 PM, Joshua D. Drake j...@commandprompt.com wrote: Hello, Something that continues to grind my teeth about our software is that we are horribly inconsistent with our system catalogs. Now I am fully and 100%

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Dave Page
On Wed, Mar 4, 2009 at 9:09 PM, Joshua D. Drake j...@commandprompt.com wrote: I assume you'll be putting in the weeks/months of work required to fix pgAdmin phpPgAdmin which would be far better spent on new features than uglifying the code in far nastier ways than the current state of the

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Joshua D. Drake
On Wed, 2009-03-04 at 21:14 +, Dave Page wrote: On Wed, Mar 4, 2009 at 9:09 PM, Joshua D. Drake j...@commandprompt.com wrote: *Shrug* long term consistency is the better choice. Easy to say if you're not one of the people for whom such a change would mean weeks of recoding, the need

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Bill Moran
In response to Dave Page dp...@pgadmin.org: On Wed, Mar 4, 2009 at 9:09 PM, Joshua D. Drake j...@commandprompt.com wrote: I assume you'll be putting in the weeks/months of work required to fix pgAdmin phpPgAdmin which would be far better spent on new features than uglifying the code

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Dave Page
On Wed, Mar 4, 2009 at 9:23 PM, Joshua D. Drake j...@commandprompt.com wrote: It is not easy to say. It is correct to say. I am under no illusion that this will not be painful. As far as man weeks of recoding. Sorry, I know that will be tough. It'll be a complete and utter waste of time, and

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Tom Lane
Joshua D. Drake j...@commandprompt.com writes: Something that continues to grind my teeth about our software is that we are horribly inconsistent with our system catalogs. Now I am fully and 100% aware that changing this will break things in user land but I want to do it anyway. In order to do

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Dave Page
On Wed, Mar 4, 2009 at 9:24 PM, Bill Moran wmo...@potentialtech.com wrote: In response to Dave Page dp...@pgadmin.org: Don't those folks have to tweak their code with each new release anyway? Because those tables are constantly changing?  I know we hit problems with the way triggers are

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Joshua D. Drake
On Wed, 2009-03-04 at 21:27 +, Dave Page wrote: On Wed, Mar 4, 2009 at 9:23 PM, Joshua D. Drake j...@commandprompt.com wrote: It is not easy to say. It is correct to say. I am under no illusion that this will not be painful. As far as man weeks of recoding. Sorry, I know that will

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Joshua D. Drake
On Wed, 2009-03-04 at 16:28 -0500, Tom Lane wrote: Joshua D. Drake j...@commandprompt.com writes: Something that continues to grind my teeth about our software is that we are horribly inconsistent with our system catalogs. Now I am fully and 100% aware that changing this will break things

Re: [HACKERS] cbrt() broken in AIX

2009-03-04 Thread Tom Lane
=?ISO-8859-1?Q?Andr=E9_Volpato?= andre.volp...@ecomtecnologia.com.br writes: First I tryed to configure with no options, and then make throw this: float.c:74: error: static declaration of 'cbrt' follows non-static declaration After some googling, I find Bruce´s path back on 7.4, that removed

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Magnus Hagander
Joshua D. Drake wrote: On Wed, 2009-03-04 at 21:27 +, Dave Page wrote: On Wed, Mar 4, 2009 at 9:23 PM, Joshua D. Drake j...@commandprompt.com wrote: It is not easy to say. It is correct to say. I am under no illusion that this will not be painful. As far as man weeks of recoding. Sorry,

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Kevin Grittner
Joshua D. Drake j...@commandprompt.com wrote: It would lower the cost (intellectually as well as dollars) of development and administration for every single user of the database. -1 Any savings couldn't possibly pay for the cost and pain of this, at least in our shop. I can't count how

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Tom Lane
Magnus Hagander mag...@hagander.net writes: I think this sounds a lot like another request for a set of system views with nicer names. What's the state of the newsysviews project, anyway? I don't recall hearing much about it lately. regards, tom lane -- Sent via

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Josh Berkus
Joshua D. Drake wrote: Hello, Something that continues to grind my teeth about our software is that we are horribly inconsistent with our system catalogs. Now I am fully and 100% aware that changing this will break things in user land but I want to do it anyway. In order to do that I believe we

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Josh Berkus
Tom Lane wrote: Magnus Hagander mag...@hagander.net writes: I think this sounds a lot like another request for a set of system views with nicer names. What's the state of the newsysviews project, anyway? I don't recall hearing much about it lately. Final verdict was that we need to make it

Re: [HACKERS] SYNONYMs revisited

2009-03-04 Thread Jonah H. Harris
On Wed, Mar 4, 2009 at 9:34 AM, Joshua Tolley eggyk...@gmail.com wrote: Way back in this thread[1] one of the arguments against allowing some version of CREATE SYNONYM was that we couldn't create a synonym for an object in a remote database. Will the SQL/MED work make this sort of thing a

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Josh Berkus
Well, honestly, this was one of the reasons why AndrewSN, David and I ... and Elein ... pushed NewSysViews. Non-hackers really shouldn't be accessing the system catalogs directly, and if information_schema doesn't give them enough data, we should start adding new views to I_S. -- Sent

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Josh Berkus
Bill, You could always take a survey ... bosses love surveys ... Done: http://wwwmaster.postgresql.org/community/ --Josh -- 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] Prepping to break every past release...

2009-03-04 Thread Andrew Dunstan
Josh Berkus wrote: Well, honestly, this was one of the reasons why AndrewSN, David and I ... and Elein ... pushed NewSysViews. Non-hackers really shouldn't be accessing the system catalogs directly, and if information_schema doesn't give them enough data, we should start adding new

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Kevin Grittner
Andrew Dunstan and...@dunslane.net wrote: Back on that track, I'd like to see a facility whereby we could provide an alias (or synonym, to use a nearby subject) columns and other objects. That would help to overcome naming glitches without breaking things quite so much. How is that

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Kevin Grittner
Josh Berkus j...@agliodbs.com wrote: You could always take a survey ... bosses love surveys ... Done: http://wwwmaster.postgresql.org/community/ Is there some assumed relationship between those options and whether they'd like to see the names changed? Also, it's hard to pick what option

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Josh Berkus
Andrew, Back on that track, I'd like to see a facility whereby we could provide an alias (or synonym, to use a nearby subject) columns and other objects. That would help to overcome naming glitches without breaking things quite so much. Believe it or not, a large PostgreSQL user in LA just

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Josh Berkus
Kevin Grittner wrote: Josh Berkus j...@agliodbs.com wrote: You could always take a survey ... bosses love surveys ... Done: http://wwwmaster.postgresql.org/community/ Is there some assumed relationship between those options and whether they'd like to see the names changed? Also, it's hard

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread A.M.
On Mar 4, 2009, at 6:07 PM, Josh Berkus wrote: Andrew, Back on that track, I'd like to see a facility whereby we could provide an alias (or synonym, to use a nearby subject) columns and other objects. That would help to overcome naming glitches without breaking things quite so much.

Re: [HACKERS] cbrt() broken in AIX

2009-03-04 Thread Dickson S. Guedes
2009/3/4 André Volpato andre.volp...@ecomtecnologia.com.br: I´m trying to install postgres 8.3.6 at AIX 5.3, and I got a declaration error that I presume its related to this [1] thread. Here´s some info: - Bladecenter IBM JS22 - PowerPC_POWER6 quad 4GHZ 64 bits - AIX 5.3.0 - Postgresql

Re: [HACKERS] V4 of PITR performance improvement for 8.4

2009-03-04 Thread Koichi Suzuki
Appreciate for your kind help! 2009/3/3 Fujii Masao masao.fu...@gmail.com: On Tue, Mar 3, 2009 at 1:47 PM, Fujii Masao masao.fu...@gmail.com wrote: Hi Suzuki-san, On Thu, Feb 26, 2009 at 5:03 AM, Koichi Suzuki koichi@gmail.com wrote: My reply to Gregory's comment didn't have any

Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1668)

2009-03-04 Thread KaiGai Kohei
Heikki, Thanks for your comments. Heikki Linnakangas wrote: Ok, I've taken a quick look at this too. My first impression is that this is actually not a very big patch. Much much smaller than I was afraid of. It seems that dropping the row-level security and the other change you've already

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Andrew Gierth
Tom == Tom Lane t...@sss.pgh.pa.us writes: Magnus Hagander mag...@hagander.net writes: I think this sounds a lot like another request for a set of system views with nicer names. Tom What's the state of the newsysviews project, anyway? I don't Tom recall hearing much about it lately.

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Robert Haas
On Wed, Mar 4, 2009 at 3:32 PM, Joshua D. Drake j...@commandprompt.com wrote: Something that continues to grind my teeth about our software is that we are horribly inconsistent with our system catalogs. Now I am fully and 100% aware that changing this will break things in user land but I want

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Greg Smith
On Wed, 4 Mar 2009, Joshua D. Drake wrote: Something that continues to grind my teeth about our software is that we are horribly inconsistent with our system catalogs. I'd suggest staring at the gyrations required to do an in-place upgrade, then considering how the changes you're suggesting

Re: [HACKERS] Prepping to break every past release...

2009-03-04 Thread Stephen Frost
* Robert Haas (robertmh...@gmail.com) wrote: Like everyone else who has responded to this thread, I think this is a pretty terrible idea. [...] +1 on Robert's assessment from me. I'm generally a huge fan of doing the right thing, but as my boss often likes to point out, you need to pick your

[HACKERS] [BUG] Column-level privileges on inherited tables

2009-03-04 Thread KaiGai Kohei
I've observed the behavior of column-level privileges and required permissions with a few elog()s injected. I noticed rte-selectedCols is incorrect when we make a query on inherited tables. See below: - postgres=# CREATE TABLE t1 (a int, b int, c

Re: [HACKERS] [BUG] Column-level privileges on inherited tables

2009-03-04 Thread KaiGai Kohei
KaiGai Kohei wrote: I've observed the behavior of column-level privileges and required permissions with a few elog()s injected. I noticed rte-selectedCols is incorrect when we make a query on inherited tables. See below: - postgres=#

[HACKERS] Patch for the MUST time zone (Mauritius Summer Time)

2009-03-04 Thread Xavier Bugaud
Hi, This trivial patch allows PostgreSQL to understand the MUST (Mauritius Summer Time) time zone that is in used since 2008-11. Before the patch : # SELECT '2009-03-15 14:54:15 MUST'::timestamp; ERROR: invalid input syntax for type timestamp: 2009-03-15 14:54:15 MUST After the patch : #

Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1668)

2009-03-04 Thread Heikki Linnakangas
KaiGai Kohei wrote: The other one is it has two kind of reader permissions (select and use). The select permission is applied when user tries to read tables/columns and its contents are returned to the user. The use permission is applied when user tries to read table/columns, but its contents

Re: [HACKERS] Patch for the MUST time zone (Mauritius Summer Time)

2009-03-04 Thread Heikki Linnakangas
Xavier Bugaud wrote: This trivial patch allows PostgreSQL to understand the MUST (Mauritius Summer Time) time zone that is in used since 2008-11. ... *** src/timezone/tznames/Default1 May 2008 20:05:08 - 1.6 --- src/timezone/tznames/Default5 Mar 2009 07:03:19 -

Re: [HACKERS] [BUG] Column-level privileges on inherited tables

2009-03-04 Thread KaiGai Kohei
Stephen, The attached patch fixes the matter. It fixes up attribute number of child relation when it is extracted. (*) Injected elog()s are removed. postgres=# select * from t1; NOTICE: markRTEForSelectPriv: ACL_SELECT on t1.a NOTICE: markRTEForSelectPriv: ACL_SELECT on t1.c NOTICE:

[HACKERS] Use array in a dynamic statement

2009-03-04 Thread Sophie Yang
Hi, I am trying to implement a PL/PgSQL function as following: CREATE OR REPLACE FUNCTION sort_by_d_idx (nids INT[][], tbl_name VARCHAR) RETURNS varchar[] AS $$ DECLARE result varchar[]; BEGIN EXECUTE 'SELECT ARRAY(SELECT t.idx FROM generate_series(array_lower($1,1), array_upper($1,1)) AS

Re: [HACKERS] Patch for the MUST time zone (Mauritius Summer Time)

2009-03-04 Thread Xavier Bugaud
On Thursday 05 March 2009 12:31:17 Heikki Linnakangas wrote: Xavier Bugaud wrote: This trivial patch allows PostgreSQL to understand the MUST (Mauritius Summer Time) time zone that is in used since 2008-11. ... *** src/timezone/tznames/Default1 May 2008 20:05:08 -

Re: [HACKERS] Use array in a dynamic statement

2009-03-04 Thread Heikki Linnakangas
Sophie Yang wrote: I am trying to implement a PL/PgSQL function as following: CREATE OR REPLACE FUNCTION sort_by_d_idx (nids INT[][], tbl_name VARCHAR) RETURNS varchar[] AS $$ DECLARE result varchar[]; BEGIN EXECUTE 'SELECT ARRAY(SELECT t.idx FROM generate_series(array_lower($1,1),