Re: [HACKERS] [PATCHES] replication docs: split single vs. multi-master

2006-11-17 Thread Markus Schiltknecht
Hello Bruce, You wrote: I am still feeling that data partitioning is like master/slave replication because you have to get that read-only copy to the other server. Yes, that's where replication comes into play. But data partitioning per se has nothing to do with replication, has it? You

Re: [HACKERS] [PATCHES] replication docs: split single vs. multi-master

2006-11-17 Thread Markus Schiltknecht
Good morning Hannu, Hannu Krosing wrote: People do that in cases where there is high write loads (high as in not 10+ times less than reads) and just replicating the RO copies would be prohibitively expensive in either network, cpu or memory terms. Okay. It that case it's even less like any

Re: [HACKERS] ALTER TABLE RENAME column

2006-11-17 Thread Richard Huxton
Peter Eisentraut wrote: Jim Nasby wrote: Any reason not to support renaming columns? Can this be added to TODO? Upgrade to Postgres95. Hey, is Jim running MySQL 5? -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 9: In

Re: [HACKERS] Frequent Update Project: Design Overview ofHOTUpdates

2006-11-17 Thread Hannu Krosing
Ühel kenal päeval, E, 2006-11-13 kell 13:42, kirjutas Csaba Nagy: [snip] IMHO *most* UPDATEs occur on non-indexed fields. [snip] If my assumption is badly wrong on that then perhaps HOT would not be useful after all. If we find that the majority of UPDATEs meet the HOT pre-conditions,

[HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Teodor Sigaev
Hi! Now we (Oleg and me) are working on moving tsearch into core. Pls, review suggested syntax. Comments, suggestions, objections will be appreciated. 1) parser operation (pg_ts_parser table) CREATE PARSER prsname ( START = funcname, GETTOKEN = funcname, END =

Re: [HACKERS] Frequent Update Project: Design Overview ofHOTUpdates

2006-11-17 Thread Simon Riggs
On Fri, 2006-11-17 at 13:30 +0200, Hannu Krosing wrote: Ühel kenal päeval, E, 2006-11-13 kell 13:42, kirjutas Csaba Nagy: [snip] IMHO *most* UPDATEs occur on non-indexed fields. [snip] If my assumption is badly wrong on that then perhaps HOT would not be useful after all. If we

Re: [HACKERS] [PATCHES] replication docs: split single vs.

2006-11-17 Thread Bruce Momjian
Hannu Krosing wrote: OK. I am still feeling that data partitioning is like master/slave replication because you have to get that read-only copy to the other server. If you split things up so data sets resided on only one machine, you are right that would not be replication, but do people

Re: [HACKERS] [PATCHES] replication docs: split single vs.

2006-11-17 Thread Bruce Momjian
Hannu Krosing wrote: ?hel kenal p?eval, R, 2006-11-17 kell 00:01, kirjutas Bruce Momjian: Current version at: http://momjian.us/main/writings/pgsql/sgml/failover.html it refers to Warm Standby Using Point-In-Time Recovery

Re: [HACKERS] [PATCHES] replication docs: split single vs.

2006-11-17 Thread Bruce Momjian
Markus Schiltknecht wrote: Hello Bruce, You wrote: I am still feeling that data partitioning is like master/slave replication because you have to get that read-only copy to the other server. Yes, that's where replication comes into play. But data partitioning per se has nothing to

Re: [HACKERS] ALTER TABLE RENAME column

2006-11-17 Thread Jonah H. Harris
On 11/16/06, Jim Nasby [EMAIL PROTECTED] wrote: Any reason not to support renaming columns? Can this be added to TODO? ALTER TABLE yo_table RENAME COLUMN yo_column TO yo_new_column; ? -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation| fax:

Re: [HACKERS] ALTER TABLE RENAME column

2006-11-17 Thread Andrew Dunstan
Jonah H. Harris wrote: On 11/16/06, Jim Nasby [EMAIL PROTECTED] wrote: Any reason not to support renaming columns? Can this be added to TODO? ALTER TABLE yo_table RENAME COLUMN yo_column TO yo_new_column; Maybe Jim actually wants a reason to remove support for this ... :-) cheers andrew

Re: [HACKERS] ALTER TABLE RENAME column

2006-11-17 Thread Mario Weilguni
Uh, we did that years ago. Really? + o Add ALTER TABLE RENAME COLUMN (should rename appropriate sequences and constraints) Sounds like this is not done, at least not renaming sequencens and constraints, or am I wrong here? Regard Mario Weilguni -Ursprüngliche Nachricht-

Re: [HACKERS] Frequent Update Project: Design Overview

2006-11-17 Thread Kevin Grittner
On Fri, Nov 17, 2006 at 5:30 AM, in message [EMAIL PROTECTED], Hannu Krosing [EMAIL PROTECTED] wrote: Ühel kenal päeval, E, 2006-11-13 kell 13:42, kirjutas Csaba Nagy: [snip] IMHO *most* UPDATEs occur on non-indexed fields. [snip] If my assumption is badly wrong on that then perhaps

Re: [HACKERS] ALTER TABLE RENAME column

2006-11-17 Thread Jonah H. Harris
On 11/17/06, Mario Weilguni [EMAIL PROTECTED] wrote: Sounds like this is not done, at least not renaming sequencens and constraints, or am I wrong here? To rename a sequence or a table: ALTER TABLE yo_table RENAME TO yo_new_table; ALTER TABLE yo_sequence RENAME TO yo_new_sequence; Or am I

Re: [HACKERS] ALTER TABLE RENAME column

2006-11-17 Thread Jonah H. Harris
On 11/17/06, Mario Weilguni [EMAIL PROTECTED] wrote: + o Add ALTER TABLE RENAME COLUMN (should rename appropriate sequences and constraints) Actually, I don't believe it cascades the rename automagically... if that's what you're asking. -- Jonah H. Harris, Software Architect | phone:

Re: [HACKERS] ALTER TABLE RENAME column

2006-11-17 Thread Mario Weilguni
Right, but I think jim means automatical renames of sequences, and especially something like this: db=# CREATE TABLE foo (bar serial); NOTICE: CREATE TABLE will create implicit sequence foo_bar_seq for serial column foo.bar CREATE TABLE db=# ALTER TABLE foo rename bar to baf; ALTER TABLE db=#

Re: [HACKERS] ALTER TABLE RENAME column

2006-11-17 Thread Tom Lane
Mario Weilguni [EMAIL PROTECTED] writes: IMO this should do: Alter sequence foo_bar_seq rename to foo_baf_seq; Alter table foo alter baf set default nextval('foo_baf_seq') No, it should not, because that risks breaking other references to the sequence (eg, in user-written functions). If the

Re: [HACKERS] ALTER TABLE RENAME column

2006-11-17 Thread Jonah H. Harris
On 11/17/06, Tom Lane [EMAIL PROTECTED] wrote: No, it should not, because that risks breaking other references to the sequence (eg, in user-written functions). If the user is feeling that he wants consistency, he can rename the sequence himself and take responsibility for any side-effects on

Re: [HACKERS] [PATCHES] replication docs: split single vs.

2006-11-17 Thread Bruce Momjian
I have renamed the documentation section High Availability and Load Balancing. I think the current version takes many of your comments below into account. Please let me know. --- Markus Schiltknecht wrote: Good morning

[HACKERS] Day and month name localization uses wrong locale category

2006-11-17 Thread Peter Eisentraut
In 8.2, utils/adt/formatting.c uses our NLS mechanism to localize day and month names (I assume for use by to_char). But since this necessarily ties the outcome to the LC_MESSAGES setting, this comes out inconsistently with Unix locale behavior, e.g., [EMAIL PROTECTED]:~$ locale LANG=

[HACKERS] Localization of abbreviated day names

2006-11-17 Thread Peter Eisentraut
Another issue regarding the to_char localization: DY is documented to use 3 characters, but in German week names are abbreviated to 2 characters. Other languages will likely have related issues. What should we do here? I'd favor that we change the 3 characters to some fixed length. Other

Re: [HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Tom Lane
Teodor Sigaev [EMAIL PROTECTED] writes: Now we (Oleg and me) are working on moving tsearch into core. Pls, review suggested syntax. Comments, suggestions, objections will be appreciated. Is it really necessary to invent a batch of special-purpose commands? Seems like this will add some

Re: [HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Teodor Sigaev
Hmm, IMHO, it's needed for consistent interface: nobody adds new column to table by editing pg_class pg_attribute, nobody looks for description of table by selection values from system table. Tom Lane wrote: Teodor Sigaev [EMAIL PROTECTED] writes: Now we (Oleg and me) are working on moving

Re: [HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Andrew Dunstan
Teodor Sigaev wrote: Hmm, IMHO, it's needed for consistent interface: nobody adds new column to table by editing pg_class pg_attribute, nobody looks for description of table by selection values from system table. Tom Lane wrote: Teodor Sigaev [EMAIL PROTECTED] writes: Now we (Oleg and me)

Re: [HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Oleg Bartunov
On Fri, 17 Nov 2006, Andrew Dunstan wrote: Teodor Sigaev wrote: Hmm, IMHO, it's needed for consistent interface: nobody adds new column to table by editing pg_class pg_attribute, nobody looks for description of table by selection values from system table. Tom Lane wrote: Teodor Sigaev

Re: [HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Alvaro Herrera
Oleg Bartunov wrote: On Fri, 17 Nov 2006, Andrew Dunstan wrote: I am also a bit concerned that the names of the proposed objects (parser, dictionary) don't convey their purpose adequately. Maybe TS_DICTIONARY and TS_PARSER might be better if we in fact need to name them. this looks

Re: [HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Peter Eisentraut
Alvaro Herrera wrote: We should also take the opportunity to discuss new keywords for the XML support -- will we use new grammar, or functions? The XML stuff is defined in the SQL standard and there are existing implementations, so any nonstandard syntax is going to be significantly less

Re: [HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Andrew Dunstan
Alvaro Herrera wrote: Oleg Bartunov wrote: On Fri, 17 Nov 2006, Andrew Dunstan wrote: I am also a bit concerned that the names of the proposed objects (parser, dictionary) don't convey their purpose adequately. Maybe TS_DICTIONARY and TS_PARSER might be better if we in fact need

Re: [HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes: I don't see any comparable arguments about this full-text search stuff. In particular I don't see any arguments why a change would necessary at all, including why moving to core would be necessary in the first place. AFAIR the only argument in

Re: [HACKERS] Frequent Update Project: Design Overview ofHOTUpdates

2006-11-17 Thread Simon Riggs
On Fri, 2006-11-17 at 09:25 -0600, Kevin Grittner wrote: Like Hannu, we do use conditional indexes with high updates on columns in the WHERE clause, although these columns are not part of the index sequence. For example, we have a receivables table which contains a balance due. For audit

Re: [HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Jeremy Drake
On Fri, 17 Nov 2006, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: I don't see any comparable arguments about this full-text search stuff. In particular I don't see any arguments why a change would necessary at all, including why moving to core would be necessary in the first

Re: [HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: I also think the thousands of lines is an exaggeration :-) I think a reasonable comparison point is the operator-class commands, which are at least in the same general ballpark of complexity. opclasscmds.c is currently 1075 lines, and that's not counting

Re: [HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Alvaro Herrera
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: I also think the thousands of lines is an exaggeration :-) I think a reasonable comparison point is the operator-class commands, which are at least in the same general ballpark of complexity. opclasscmds.c is currently 1075 lines,

Re: [HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Oleg Bartunov
On Fri, 17 Nov 2006, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: I don't see any comparable arguments about this full-text search stuff. In particular I don't see any arguments why a change would necessary at all, including why moving to core would be necessary in the first

Re: [HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: It may be worth doing anyway --- certainly CREATE OPERATOR CLASS was a huge improvement over the previous ways of doing it --- but don't underestimate the size of what we're talking about. Hmm, actually the tsearch2 directory contains

Re: [HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Ron Mayer
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: I don't see any comparable arguments about this full-text search stuff. In particular I don't see any arguments why a change would necessary at all, including why moving to core would be necessary in the first place. AFAIR the

Re: [HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Nikolay Samokhvalov
On 11/17/06, Peter Eisentraut [EMAIL PROTECTED] wrote: Alvaro Herrera wrote: We should also take the opportunity to discuss new keywords for the XML support -- will we use new grammar, or functions? The XML stuff is defined in the SQL standard and there are existing implementations, so any

Re: [HACKERS] [GENERAL] Shutting down a warm standby database in 8.2beta3

2006-11-17 Thread Tom Lane
Stephen Harris [EMAIL PROTECTED] writes: Doing a shutdown immediate isn't to clever because it actually leaves the recovery threads running LOG: restored log file 00010001003E from archive LOG: received immediate shutdown request LOG: restored log file 00010001003F

Re: [HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Martijn van Oosterhout
On Fri, Nov 17, 2006 at 03:53:35PM -0500, Tom Lane wrote: Having the supporting code in core does not make much of a difference otherwise from having it in contrib, does it? Given the nonextensibility of gram.y and keywords.c, it has to be in core to even think about having special syntax

Re: [HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Tom Lane
Martijn van Oosterhout kleptog@svana.org writes: On Fri, Nov 17, 2006 at 03:53:35PM -0500, Tom Lane wrote: Given the nonextensibility of gram.y and keywords.c, it has to be in core to even think about having special syntax :-( Has anyone ever heard of extensible grammers? Yeah, I worked with

Re: [HACKERS] [GENERAL] Allowing SYSDATE to Work

2006-11-17 Thread Matt Miller
Redirecting from -general. I'd like SYSDATE to work syntactically and semantically the same as CURRENT_TIMESTAMP current_time and the like are hardcoded in the grammar. You'd have to do the same for sysdate. Okay, I patched. The patch follows. Please comment. In particular, I've just

Re: [HACKERS] [GENERAL] Allowing SYSDATE to Work

2006-11-17 Thread Josh Berkus
Matt, I'd like SYSDATE to work syntactically and semantically the same as CURRENT_TIMESTAMP Huh? Is SYSDATE part of the standard somewhere? -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 7: You can help

Re: [HACKERS] [GENERAL] Allowing SYSDATE to Work

2006-11-17 Thread Andrew Dunstan
Matt Miller wrote: Can't keywords share code Code blocks belong to productions. the way to do what you want I think is like this: foo: bar_or_baz { code block } ; bar_or_baz: bar | baz ; cheers andrew ---(end of broadcast)--- TIP 1:

Re: [HACKERS] zic data updates

2006-11-17 Thread Euler Taveira de Oliveira
Bruce Momjian wrote: Tom has done the zic updates to 2006n. What about update it to 2006o? It's from 11/06/2006 [1]. [1] ftp://elsie.nci.nih.gov/pub/ -- Euler Taveira de Oliveira http://www.timbira.com/ ---(end of broadcast)--- TIP 1: if

Re: [HACKERS] [COMMITTERS] pgsql: Clarify description of CIDR-address column

2006-11-17 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: Clarify description of CIDR-address column of pg_hba.conf, to discourage people from trying notations like '10.6/16', which is accepted but does not mean what you probably think. Per example from Paul Forgey. Isn't the real problem

Re: [HACKERS] [GENERAL] Allowing SYSDATE to Work

2006-11-17 Thread Tom Lane
Matt Miller [EMAIL PROTECTED] writes: I found it interesting that gram.c and parse.h already supported SYSDATE. Only after you ran bison ;-). They're derived files. regards, tom lane ---(end of broadcast)--- TIP 2: Don't

Re: [HACKERS] [COMMITTERS] pgsql: Clarify description of CIDR-address

2006-11-17 Thread Florian G. Pflug
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: Clarify description of CIDR-address column of pg_hba.conf, to discourage people from trying notations like '10.6/16', which is accepted but does not mean what you probably think. Per example from Paul Forgey. Isn't

Re: [HACKERS] Day and month name localization uses wrong locale category

2006-11-17 Thread Euler Taveira de Oliveira
Peter Eisentraut wrote: [EMAIL PROTECTED]:~$ date +%A Friday [EMAIL PROTECTED]:~$ [EMAIL PROTECTED] date +%A Friday [EMAIL PROTECTED]:~$ [EMAIL PROTECTED] date +%A Freitag Is there no API to get the localized names from the C library so that LC_TIME takes effect? What about using

Re: [HACKERS] [COMMITTERS] pgsql: Clarify description of CIDR-address column

2006-11-17 Thread Tom Lane
Florian G. Pflug [EMAIL PROTECTED] writes: Andrew Dunstan [EMAIL PROTECTED] writes: Isn't the real problem here that 10.6 doesn't mean what you probably think? I'm curious now - what _does_ 10.6/16 mean? I can't imagine any sensible meaning apart from 10.6.0.0/16... 10.6 means the same as

Re: [HACKERS] [GENERAL] Allowing SYSDATE to Work

2006-11-17 Thread Euler Taveira de Oliveira
Matt Miller wrote: Yeah, and I don't expect that they'll be a rush to commit this to head anytime soon. I'll be happy enough tracking this locally. I think it's a win for my situation. Why should we add this Oraclism to PostgreSQL? I doesn't add any new feature. I suggest you to contribute

Re: [HACKERS] zic data updates

2006-11-17 Thread Tom Lane
Euler Taveira de Oliveira [EMAIL PROTECTED] writes: Bruce Momjian wrote: Tom has done the zic updates to 2006n. What about update it to 2006o? It's from 11/06/2006 [1]. [ shrug... ] And by the time we release 8.2, it'll no doubt have changed twice more. Folks who live in countries where

Re: [HACKERS] [COMMITTERS] pgsql: Clarify description of

2006-11-17 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: Clarify description of CIDR-address column of pg_hba.conf, to discourage people from trying notations like '10.6/16', which is accepted but does not mean what you probably think. Per example from Paul Forgey. Isn't

Re: [HACKERS] [GENERAL] Shutting down a warm standby database in 8.2beta3

2006-11-17 Thread Tom Lane
Stephen Harris [EMAIL PROTECTED] writes: However, it seems the signal wasn't sent at all. Now that I think about it, the behavior of system() is predicated on the assumption that SIGINT and SIGQUIT originate with the tty driver and are broadcast to all members of the session's process group ---

Re: [HACKERS] [GENERAL] Shutting down a warm standby database in 8.2beta3

2006-11-17 Thread Stephen Harris
On Fri, Nov 17, 2006 at 10:49:39PM -0500, Tom Lane wrote: Stephen Harris [EMAIL PROTECTED] writes: However, it seems the signal wasn't sent at all. Now that I think about it, the behavior of system() is predicated on the assumption that SIGINT and SIGQUIT originate with the tty driver and

Re: [HACKERS] [GENERAL] Shutting down a warm standby database in 8.2beta3

2006-11-17 Thread Stephen Harris
On Fri, Nov 17, 2006 at 05:03:44PM -0500, Tom Lane wrote: Stephen Harris [EMAIL PROTECTED] writes: Doing a shutdown immediate isn't to clever because it actually leaves the recovery threads running LOG: restored log file 00010001003E from archive LOG: received immediate

Re: [HACKERS] [GENERAL] Shutting down a warm standby database in 8.2beta3

2006-11-17 Thread Gregory Stark
Stephen Harris [EMAIL PROTECTED] writes: My script was just a ksh script and didn't do anything special with signals. Essentially it does #!/bin/ksh -p [...variable setup...] while [ ! -f $wanted_file ] do if [ -f $abort_file ] then exit 1 fi sleep 5

Re: [HACKERS] [GENERAL] Shutting down a warm standby database in 8.2beta3

2006-11-17 Thread Stephen Harris
On Fri, Nov 17, 2006 at 09:39:39PM -0500, Gregory Stark wrote: Stephen Harris [EMAIL PROTECTED] writes: [...variable setup...] while [ ! -f $wanted_file ] do if [ -f $abort_file ] then exit 1 fi sleep 5 done cat $wanted_file I know signals

Re: [HACKERS] Indicate disabled triggers in \d

2006-11-17 Thread Bruce Momjian
This has been saved for the 8.3 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Brendan Jurd wrote: On 11/7/06, Brendan Jurd [EMAIL PROTECTED] wrote: As discussed briefly on pgsql-hackers, the

Re: [HACKERS] [GENERAL] Shutting down a warm standby database in 8.2beta3

2006-11-17 Thread Tom Lane
Stephen Harris [EMAIL PROTECTED] writes: On Fri, Nov 17, 2006 at 10:49:39PM -0500, Tom Lane wrote: This does not apply to signals originated by the postmaster --- it doesn't even know that the child process is doing a system(), much less have any way to signal the grandchild. Ugh. Why not,

Re: [HACKERS] [PATCHES] Brazilian FAQ update

2006-11-17 Thread Tom Lane
Euler Taveira de Oliveira [EMAIL PROTECTED] writes: This is an updated version of Brazilian FAQ [1]. Where are we on this? Bruce told me earlier today that he's about 2000 emails behind after returning from his trip to the Far East. Cut him a bit of slack ... regards,

Re: [HACKERS] [GENERAL] Shutting down a warm standby database in 8.2beta3

2006-11-17 Thread Tom Lane
Gregory Stark [EMAIL PROTECTED] writes: Sure, but it might be getting delivered to, say, your sleep command. You haven't checked the return value of sleep to handle any errors that may occur. As it stands you have to check for errors from every single command executed by your script. The

Re: [HACKERS] [GENERAL] Shutting down a warm standby database in 8.2beta3

2006-11-17 Thread Gregory Stark
Tom Lane [EMAIL PROTECTED] writes: Gregory Stark [EMAIL PROTECTED] writes: Sure, but it might be getting delivered to, say, your sleep command. You haven't checked the return value of sleep to handle any errors that may occur. As it stands you have to check for errors from every single

Re: [HACKERS] [GENERAL] Shutting down a warm standby database in 8.2beta3

2006-11-17 Thread Tom Lane
Gregory Stark [EMAIL PROTECTED] writes: Hm, I tried to test that before I sent that. But I guess my test was faulty since I was really testing what process the terminal handling delivered the signal to: Interesting. I tried the same test on HPUX, and find that its /bin/sh seems to ignore

Re: [HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Peter Eisentraut
Jeremy Drake wrote: I am currently in the position that my hosting provider is apprehensive about installing modules in contrib because they believe they are less secure. Using irrational and unfounded statements one can of course make arguments for just about anything, but that won't help

Re: [HACKERS] Proposal: syntax of operation with tsearch's configuration

2006-11-17 Thread Peter Eisentraut
Oleg Bartunov wrote: marketing is not always swear-word :) We live in real world and there are many situations where marketing is the deciding vote. I don't know about you, but I market PostgreSQL partially using 1. sane design, not driven by random demands 2. extensibility which would be

Re: [HACKERS] [GENERAL] Allowing SYSDATE to Work

2006-11-17 Thread Peter Eisentraut
Euler Taveira de Oliveira wrote: Matt Miller wrote: Yeah, and I don't expect that they'll be a rush to commit this to head anytime soon. I'll be happy enough tracking this locally. I think it's a win for my situation. Why should we add this Oraclism to PostgreSQL? I doesn't add any new