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
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
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
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
"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 e
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.
T
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 ...
rega
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.
>
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 drive
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_f
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 --
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
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 w
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 contrib
"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
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
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
"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: Do
"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
>
"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
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: i
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,
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: receiv
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:
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
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
Martijn van Oosterhout 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 systems tha
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 s
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
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.
>
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 "00010
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
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
pla
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
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 count
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 th
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
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
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 t
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 use
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 loo
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 <[
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 m
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 movi
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 th
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 i
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=
LC_CTYPE
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
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 h
"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
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=
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: 73
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
>>> 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 th
> 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-
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
andre
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: 732
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
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" (http://momjian.us/main/writings/pgsq
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
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
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 = funcnam
Ü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-co
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 versions
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
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 can
66 matches
Mail list logo
