The EDITOR variable seems to have a fairly standard meaning on Unix
systems. I've been using that EDITOR value for years without problems,
only when I use psql's \e once in a while it breaks. I don't think we
should deviate from what seems to be a standard practice.
Agreed, no quotes
On Mon, 15 Nov 2004 15:12:24 +0800, Christopher Kings-Lynne
[EMAIL PROTECTED] wrote:
On 7.4:
This is what we wanted to do:
IF TG_OP = 'INSERT' OR (TG_OP = 'UPDATE' AND NEW.name != OLD.name) THEN
EXECUTE x;
END IF;
However, we had to write it like this:
IF TG_OP = 'INSERT' THEN
Peter Eisentraut wrote:
It seems that in the new PL/Perl, the result of the spi_exec_query
function changes in meaning depending on the command. For a SELECT,
the value of
$res-{rows}
is a reference to an array of the result rows.
For a different command
$res-{rows}
is a scalar containing the
Neil,
I think we should not touch this right now unless you certainly know
algorithm proven to be good in general case. Did you already got some idea ?
Oleg
On Mon, 15 Nov 2004, Neil Conway wrote:
On Sun, 2004-11-14 at 18:54 -0500, Tom Lane wrote:
It's probably just a hangover from the
On Sun, Nov 14, 2004 at 10:14:06PM -0500, Bruce Momjian wrote:
John Hansen wrote:
1. Quote only on Windows.
2. Expect user to put quotes in the EDITOR value if it contains a
space-containing path.
As far I I'm aware, the options on windows are very much like those on
unix:
path containing spaces
Neil Conway [EMAIL PROTECTED] writes:
I'm not sure the right way to fix it (at least without significant
changes to the GiST API). At present, the PickSplit() method is passed a
vector of GISTENTRYs and fills in a GIST_SPLITVEC. The GISTENTRYs
correspond to the first attributes of all the
Mike Rylander [EMAIL PROTECTED] writes:
IIRC, the reason for this is that the entire IF test is passed to the
SQL engine as a SELECT statement after replacing the TG_* identifiers
with their respective values.
In this case, since OLD.name does not exist during INSERT it cannot be
replaced.
Zeugswetter Andreas DAZ SD [EMAIL PROTECTED] writes:
Agreed, no quotes on Unix. I'm just wondering what to do on Windows.
I would require the user to add quotes around his executable if it has
spaces.
set EDITOR=C:/Program Files/vim/vim63/gvim.exe -y
I think this policy is OK for the Mac
We could maybe compromise with (again, for Windows only) a policy like
double-quote unless the value already contains at least one
double-quote. This should work conveniently for everybody except the
user who wants EDITOR='gvim.exe -y' on Windows; he'll have to add
some useless-looking
On Fri, 2004-11-12 at 18:16, Andreas Pflug wrote:
Oleg I.Ivanov wrote:
Or can anybody recommend me right tool which works correcty?
You could try ERwin, but I doubt you will be luckier there.
Hmmm...been fighting with the ERwin/PostgreSQL combination, though it
works well with other
Agreed, no quotes on Unix. I'm just wondering what to do
on Windows.
I would require the user to add quotes around his
executable if it has
spaces.
set EDITOR=C:/Program Files/vim/vim63/gvim.exe -y
I think this policy is OK for the Mac OS X case, but I am
wondering if it
Magnus Hagander [EMAIL PROTECTED] writes:
Agreed, no quotes on Unix. I'm just wondering what to do
on Windows.
I don't think I've seen a single windows program that uses the EDITOR
variable. There are some ported unix tools, but that's it. Native
windows program will have a per-program
Agreed, no quotes on Unix. I'm just wondering what to do
on Windows.
I don't think I've seen a single windows program that uses
the EDITOR
variable. There are some ported unix tools, but that's it. Native
windows program will have a per-program setting for this.
The system
We could maybe compromise with (again, for Windows only) a
policy like
double-quote unless the value already contains at least one
double-quote. This should work conveniently for everybody
except the
user who wants EDITOR='gvim.exe -y' on Windows; he'll have
to add some
Magnus Hagander wrote:
I don't think I've seen a single windows program that uses the EDITOR
variable. There are some ported unix tools, but that's it. Native
windows program will have a per-program setting for this. The system
default is picked based on file extension. So I doubt it will
Peter Eisentraut wrote:
Magnus Hagander wrote:
I don't think I've seen a single windows program that uses the EDITOR
variable. There are some ported unix tools, but that's it. Native
windows program will have a per-program setting for this. The system
default is picked based on file extension. So
Marc is the one who does the actual updating, though I have it on my
list of things to do when the new release goes out since I sent him a
bunch last time. I've also been thinking we ought to update tip #7
don't forget to increase your free space map settings to something
more general like be
libpq compiled with --enable-thread-safety thinks it can set the SIGPIPE
signal handler. It thinks once is enough.
psql thinks it can arbitrarily flip the signal handler between SIG_IGN
and SIG_DFL. Ergo, after the first use of the pager for output, libpq's
SIGPIPE handling will be broken.
I
Title: RE: [HACKERS] psql \e broken again
From: Peter Eisentraut [mailto:[EMAIL PROTECTED]]
Is there a Windows port of the command-line cvs tool? That
would be a
good thing to compare with.
The one that I see most often ( and use here ) is CVSGUI ( http://www.wincvs.org/ ), which
Bort, Paul [EMAIL PROTECTED] writes:
The one that I see most often ( and use here ) is CVSGUI (
http://www.wincvs.org/ ), which includes a CVS command-line client despite
the name. ( The command-line CVS might be from CVSNT,
http://www.cvsnt.com/cvspro/ ).
So I thought I'd try a few
Title: backend died
Our customer running Postgres v. 7.3.2 reported a problem, occurring
couple times a week on three different servers, all on Solaris 9.
We enabled debugging in postgresql.conf, now it happened again;
here's the excerpt from the database log:
2004-11-13 10:01:06 [10456]
Brusser, Michael [EMAIL PROTECTED] writes:
Our customer running Postgres v. 7.3.2 reported a problem, occurring
couple times a week on three different servers, all on Solaris 9.
2004-11-13 10:01:06 [10456] DEBUG: child process (pid 19285) was
terminated by signal 10
SIGBUS iirc.
What
Title: RE: [HACKERS] backend died
Brusser, Michael [EMAIL PROTECTED] writes:
Our customer running Postgres v. 7.3.2 reported a problem, occurring
couple times a week on three different servers, all on Solaris 9.
2004-11-13 10:01:06 [10456] DEBUG: child process (pid 19285) was
Brusser, Michael [EMAIL PROTECTED] writes:
2004-11-13 10:01:06 [10456] DEBUG: child process (pid 19285) was
terminated by signal 10
The log-statements option was already enabled,
here's what I see prior to the crash:
That's no help. What were the last few lines from process 19285?
This
Title: RE: [HACKERS] backend died
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 15, 2004 3:34 PM
To: Brusser, Michael
Cc: Pgsql-Hackers (E-mail)
Subject: Re: [HACKERS] backend died
Brusser, Michael [EMAIL PROTECTED] writes:
Brusser, Michael [EMAIL PROTECTED] writes:
That's no help. What were the last few lines from process 19285?
there are no prior occurrences of token 19285 in the file.
Hmm, so it seems 19285 died during startup. That does make a hardware
problem seem a bit plausible --- the backend start
On Sun, 2004-11-14 at 18:29 -0500, Tom Lane wrote:
Good analysis. We can't check earlier than DefineRelation AFAICS,
because earlier stages don't know about inherited columns.
On reflection I suspect there are similar issues with SELECTs that have
more than 64K output columns. This
On Sun, 2004-11-14 at 11:24 +, Simon Riggs wrote:
This seems too obvious a problem to have caused a bug
Well, I'd imagine that we've checked CREATE TABLE et al. with
somewhat-too-large values (like 2000 columns), which wouldn't be
sufficiently large to trigger the problem.
presumably this
Neil Conway [EMAIL PROTECTED] writes:
Attached is a patch. Not entirely sure that the checks I added are in
the right places, but at any rate this fixes the three identified
problems for me.
I think the SELECT limit should be MaxTupleAttributeNumber not
MaxHeapAttributeNumber. The point of
Neil Conway [EMAIL PROTECTED] writes:
On Sun, 2004-11-14 at 11:24 +, Simon Riggs wrote:
Does this mean that we do not have
regression tests for each maximum setting ... i.e. are we missing a
whole class of tests in the regression tests?
That said, there are some minor logistical problems
On Monday 15 November 2004 11:01, Simon Riggs wrote:
On Fri, 2004-11-12 at 18:16, Andreas Pflug wrote:
Oleg I.Ivanov wrote:
Or can anybody recommend me right tool which works correcty?
You could try ERwin, but I doubt you will be luckier there.
Hmmm...been fighting with the
On Mon, 2004-11-15 at 21:08 -0500, Tom Lane wrote:
Are we going to try to test whether the behavior is appropriate when
running out of memory to store the tlist?
We absolutely should: segfaulting on OOM is not acceptable behavior.
Testing that we recover safely when palloc() elogs (or _any_
On Mon, 2004-11-15 at 10:19 -0500, Tom Lane wrote:
I'm not familiar with the details of the GiST code, but would it work to
generalize PickSplit to return a three-way classification? That is,
instead of actually splitting the node, have it identify each item as
definitely left, definitely
Excuse me for a possible offtopic,
But can anybody help me to understand why Sybase Power
Designer 10.1 does not understand serials and inheritance when reverse engineer
Postgres database from script.
Is it possible to teach PowerDesigner to reverse
engineer correctly ?
Or can anybody
Hi,
I just like to give POSITIVE feedback that postgresql-8.0.0beta4
compiles, installs and works fine under Mac OSX 10.3.6
(root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC) as long as you have readline
and a decent bison installed (1.875).
The regession test passes all steps:
==
On Mon, 2004-11-15 at 20:53 -0500, Tom Lane wrote:
I think the SELECT limit should be MaxTupleAttributeNumber not
MaxHeapAttributeNumber.
Ah, true -- I forgot about the distinction...
What I think needs to happen is to check p_next_resno at some point
after the complete tlist has been built.
36 matches
Mail list logo
