hello,
I have a problem with a rule "on insert"
I have a table "my_table" with a field named "index"
that has a default value of "nextval('seq')"
and the folowing rule
--
CREATE RULE log_ins AS ON INSERT TO my_table
DO INSERT INTO
At 12:18 PM 10/27/00 -0400, Tom Lane wrote:
Hiroshi was a little concerned about this change in behavior, and
so the first order of business is whether anyone wants to defend the
old way? IMHO it was incontrovertibly a bug, but ...
Sure feels like a bug to me. Having it ignored isn't what I'd
Kevin O'Gorman writes:
I did a 'su root' and a 'make install', then as my normal user
self, attempted to do the regression tests. They failed and
left the attached file in install.log. It points at a problem
with permissions on a file left behind by the 'make install'
in the Perl stuff.
Lamar Owen writes:
Getting the installation that 'make install' spits out massaged into
an FHS compliant setup is the majority of the RPM's spec file.
./configure --prefix=/usr --sysconfdir=/etc
Off you go... (I'll refrain from commenting further on the FHS.)
* Upgrades that don't
On Fri, 27 Oct 2000, Alex Pilosov wrote:
BTW, does it strike anyone else as peculiar that the host(),
broadcast(), network(), and netmask() functions yield results
of type text, rather than type inet? Seems like it'd be considerably
more useful if they returned values of type inet with
Applied. Thanks.
Okay, here's my attempt at fixing the problems with parentheses in
subqueries. It passes the normal 'runcheck' tests, and I've tried
a few simple things like
select 1 as foo union (select 2) order by foo;
There are a few things that it doesn't do that have
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Of course, people who manage to invoke a 6.5 or 7.0 initdb script aren't
going to be helped anyway by defenses we put into 7.1 initdb :-(.
It just occured to me that people invoking pre-7.1 initdbs with new input
files are not
"Vadim Mikheev" [EMAIL PROTECTED] writes:
2. smgrunlink() normally will NOT immediately delete the file; instead it
will perform smgrclose() and then add the rel's RelFileNode information to
^^^
Seems that smgrclose still need in Relation (where rd_fd lives and this is
Tom Lane wrote:
One thing I noticed that may surprise: the "%left UNION" and such that
appear in the source don't seem to do anything. I think our syntax
doesn't look like operators to yacc, and I suspect it's the opt_all
that's doing it. That part of yacc I don't understand.
Hmm,
On Sat, 28 Oct 2000, Larry Rosenman wrote:
Err, with Tom's objections, why was this applied?
was going to ask this too ... someone going patch-happy again? :)
* Bruce Momjian [EMAIL PROTECTED] [001028 11:34]:
Applied. Thanks.
Okay, here's my attempt at fixing the problems with
Mmmm, why not call FlushRelationBuffers? Calling bufmgr from smgr
doesn't look like right thing. ?
Yes, it's a little bit ugly, but if we call FlushRelationBuffers then we
will likely be doing some useless writes (to flush out pages that we are
only going to throw away anyway). If we
Concur.
++ kevin
Subject: Re: Gram.y patches for better parenthesis handling.
Date: Sat, 28 Oct 2000 12:41:19 -0400
From: Tom Lane [EMAIL PROTECTED]
To: Larry Rosenman [EMAIL PROTECTED]
CC: PGSQL Hackers List [EMAIL PROTECTED], [EMAIL PROTECTED]
References: [EMAIL PROTECTED] [EMAIL
Now that we have numeric file names, I would like to have a command I
can run from psql that will dump a mapping of numeric file name to table
name, i.e.,
121233 pg_proc
143423 pg_index
With that feature, I can write scripts pgfile2name and pgname2file that
map file names to
Not to put too fine a point on it, but are you talking about the
original grammar or your modified one? Your modified one is erroneous
because it will always associate successive UNION/INTERSECT/EXCEPT
operators left-to-right; this does not meet the SQL spec which insists
that INTERSECT
"Vadim Mikheev" [EMAIL PROTECTED] writes:
BTW, why do we force buffers to disk in FlushRelationBuffers at all?
Seems all what is required is to flush them *from* pool, not *to* disk
immediately.
Good point. Seems like it'd be sufficient to do a standard async write
rather than write + fsync.
With that feature, I can write scripts pgfile2name and pgname2file that
map file names to table names. People can run standard Unix commands
and have meaningful display output:
ls -l | pgfile2name
sed `psql -Aqt -d ${database} -c "select'-e s/' || oid || '/' || relname || '/g'
Bruce Momjian writes:
Now that we have numeric file names, I would like to have a command I
can run from psql that will dump a mapping of numeric file name to table
name, i.e.,
121233 pg_proc
143423 pg_index
select oid, relname from pg_class;
Oh, we went with
BTW, why do we force buffers to disk in FlushRelationBuffers at all?
Seems all what is required is to flush them *from* pool, not *to* disk
immediately.
Good point. Seems like it'd be sufficient to do a standard async write
rather than write + fsync.
We'd still need some additional
Now that we have numeric file names, I would like to have a command I
can run from psql that will dump a mapping of numeric file name to table
name, i.e.,
121233 pg_proc
143423 pg_index
select oid, relname from pg_class;
No. select relfilenode, relname from pg_class - in theory
I have that version. I am, however, compiling with a NON-GCC
compiler.
Larry
* Tatsuo Ishii [EMAIL PROTECTED] [001028 20:16]:
They still die today. I did some looking, but I'm not sure how to fix
it.
Apparently we need to have access to src/backend/utils/mb/common.c's
object file
* Larry Rosenman [EMAIL PROTECTED] [001028 20:25]:
I have that version. I am, however, compiling with a NON-GCC
compiler.
Ok, just re-cvs'd, and still have the problem.
Configure:
CC=cc CXX=CC ./configure --prefix=/home/ler/pg-test --enable-syslog --with-CXX
--with-perl
* Tom Lane [EMAIL PROTECTED] [001028 22:15]:
Larry Rosenman [EMAIL PROTECTED] writes:
Ok, just re-cvs'd, and still have the problem.
I can't reproduce the problem either...
pg_encoding_to_char is in common.c from backend/utils/mb/. The way that
psql gets holds of it is that in a
Larry Rosenman [EMAIL PROTECTED] writes:
I did a gmake distclean before the reconfigure. There are multiple
libpq's on the system. Would LD_LIBRARY_PATH override the link spec'd
-L?
Darn if I know. Sounds like wrong-libpq is the theory to pursue,
though. Better start scrutinizing the man
YUP, it's LD_LIBRARY_PATH. We need to make sure that the BUILD
Unsets it...
$ cc -O -K inline -o psql *.o -L ../../../src/interfaces/libpq -lpq -L
/usr/local/lib -lz -lgen -lld -lnsl -lsocket -ldl -lm -lreadline
-ltermcap -lcurses
Undefined first referenced
symbol
* Larry Rosenman [EMAIL PROTECTED] [001028 22:28]:
LD_LIBRARY_PATH needs to go while building
It *IS* in the manpage at the very end. Now, how do we deal with this
little bugaboo?
LER
* Tom Lane [EMAIL PROTECTED] [001028 22:22]:
Larry Rosenman [EMAIL PROTECTED] writes:
I did a
Someone's been spending too much time on C code...
the current initdb.sh uses == which doesn't work.
Here's a patch:
Index: initdb.sh
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/bin/initdb/initdb.sh,v
retrieving revision
Guy Fraser [EMAIL PROTECTED] writes:
I have tried reformatting dates in many ways but every thing I have
tried fails.
As a rule, COPY will interpret incoming dates according to the current
setting of the DATESTYLE variable. It'd help if you explained the date
format you are trying to read and
They still die today. I did some looking, but I'm not sure how to fix
it.
Apparently we need to have access to src/backend/utils/mb/common.c's
object file for the psql build. Not sure how to get there...
Larry
* Larry Rosenman [EMAIL PROTECTED] [001027 07:26]:
Todays Sources still die:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
3. We will add explicit functions cidr(inet) and inet(cidr) to force
the data type to one or the other style, thus allowing selection
of either display style. Note that cidr(inet) will raise an error
if given something with
Larry Rosenman [EMAIL PROTECTED] writes:
Err, with Tom's objections, why was this applied?
* Bruce Momjian [EMAIL PROTECTED] [001028 11:34]:
Applied. Thanks.
Itchy trigger finger today, Bruce?
Please revert the change --- I'm still discussing it with Kevin offlist,
but I don't
30 matches
Mail list logo
