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 1
* 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:
>
LD_LIBRARY_PATH needs to go while building
* Tom Lane <[EMAIL PROTECTED]> [001028 22:22]:
> 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?
>
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]> 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
* 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
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 MULTIBYTE build, common.c is built
and included in libp
* 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 --enable-mul
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
> > ob
> 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 Sou
> > 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 -
> > 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 add
> 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 we
> > 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 || '/' || relna
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;
> With that feature, I ca
"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 + fs
> 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
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 t
"Kevin O'Gorman" <[EMAIL PROTECTED]> writes:
>> Don't you get shift/reduce errors if you remove those precedence specs?
>> I'd expect the grammar to be ambiguous without operator
>> precedence specs ...
> Yah. I would have thought so too. However, when I comment out the
> two %left lines (bein
> 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
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]
> > 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). I
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 pr
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.
"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 thi
> 1. smgrcreate() will create the file for the relation same as it does now,
> and will add the rel's RelFileNode information to an smgr-private list of
> rels created in the current transaction.
>
> 2. smgrunlink() normally will NOT immediately delete the file; instead it
> will perform smgrclose
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 wi
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:
>
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 feel
Err, with Tom's objections, why was this applied?
* Bruce Momjian <[EMAIL PROTECTED]> [001028 11:34]:
> 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 lik
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
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 going to get very far because the bki files have
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
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 ine
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 r
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 stuf
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
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 nonzeroes to the right of the netmask.
Tom Lane writes:
> Hm. I don't see any really good reason why host() rejects CIDR input
> in the first place. What's wrong with producing the host address
> that corresponds to extending the CIDR network address with zeroes?
Because it's semantically wrong. It's just as wrong as converting DA
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 log(tbl,idrow,q
Just tested this on latest devel. version, and there does seem to be a
problem.
[]$ psql test
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate
41 matches
Mail list logo
