Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor writes:
>
> > An approach I've followed in the past is to use three-way logic. If
> > configuring for a native system, compile and run a program which
> > provides a yes or no answer. When using cross-configuration, set the
> > co
I have added this email thread to TODO.detail.
> We've expended a lot of worry and discussion in the past about what
> happens if the OID generator wraps around. However, there is another
> 4-byte counter in the system: the transaction ID (XID) generator.
> While OID wraparound is survivable, i
You may find 7.1beta has fixed this. I know some include files were
rearranged in 7.1.
> Hi Bruce, Hi Michael,
>
> here is the really short patch for shutting out all postgres definitions
> from ecpg
> programs. (e.g. Datum, Pointer, DEBUG, ERROR).
> Someone really should take a look into libp
Are there any open items related to the BIT type?
> Tom Lane wrote:
> >
> > I have made a first cut at completing integration of Adriaan Joubert's
> > BIT code into the backend. There are a couple little things left to
> > do (for example, scalarltsel doesn't know what to do with BIT values)
>
It is reported that building C++ interface on FreeBSD 4.2 fails.
Can someone comment on this?
c++ -pipe -O3 -mpentiumpro -Wall -fpic -DPIC -I/usr/local/ssl/include
-I../../../src/include -I../../../src/interfaces/libpq -c -o pgconnec
tion.o pgconnection.cc
In file included from ../../../src/incl
I believe this has been fixed.
>Subject: [COMMITTERS] pgsql/src/backend/utils/adt (varchar.c)
>From: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Date: Sun, 26 Nov 2000 06:35:23 -0500 (EST)
> Can someone comment on the status of this?
>
> > It seems the length coerce for bpchar is broken since 7.0
I see now that this has been applied. Thanks for pointing it out.
RuleActionStmt: SelectStmt
| InsertStmt
| UpdateStmt
| DeleteStmt
| NotifyStmt
;
> I suggest
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Can someone comment on the status of this?
regression=# create table foo (f1 char(7));
CREATE
regression=# insert into foo values ('123456789');
INSERT 145180 1
regression=# select * from foo;
f1
-
1234567
(1 row)
Where's the problem?
Can someone comment on this? I believe we were waiting for a comment
from Jan.
> I suggest that the CREATE RULE syntax be relaxed so that
> it is legal to have a list of SELECT commands in a rule.
>
> I'll argue that:
> 1) The change is simple (2 lines in gram.y). Diff is
> attached.
> 2)
Can someone comment on the status of this?
> It seems the length coerce for bpchar is broken since 7.0.
> In 6.5 when a string is inserted, bpchar() is called to properly clip
> the string. However in 7.0 (and probably current) bpchar() is not
> called anymore.
>
> coerce_type_typmod() calls e
On Fri, 19 Jan 2001, Martin A. Marques wrote:
> I had to re-compile and re-install postgresql-7.1-beta1.
> I changed the directory where it was installed from /usr/local/pgsql to
> /dbs/postgres/. After re-installing I copied the data/ directory that was
> under the old instalation to where I hav
Rob van Nieuwkerk wrote:
> Hi Mark,
>
> I just checked: the "demo.dump" file does not contain any characters
> above 0x7F; it's just plain ASCII. So that can't be the reason.
>
> greetings,
> Rob van Nieuwkerk
>
> > Rob van Nieuwkerk wrote:
I think I was close. ;-)
If I have fo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Any idea if this is fixed?
> Peter, comments?
>>
>> It doesn't destroy all databases anymore, although I can't make any
>> statements about what it actually does do. I suppose it's still broken.
Peter did put in a hack to make sure it wouldn't do "rm
Sinuhi Arroyo wrote:
> I`mtrying to make a select which envolves two tables with in a
> functionif the query is written this way: (this is just an example,
> not my query)
>
> a := (select count(*) from xx);
>
> it works fine, but if I type the query like this
>
> select count(*) from xx;
>
>
Ian Lance Taylor writes:
> An approach I've followed in the past is to use three-way logic. If
> configuring for a native system, compile and run a program which
> provides a yes or no answer. When using cross-configuration, set the
> configuration variable to ``don't know'' (or, since this a d
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Yes, definitely --- see the sole use of that macro, in outfuncs.c.
> Maybe this macro could be removed and expanded in place. That would make
> things more transparent. Or is there any other potential use?
No objection from me. The macro clearly
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> 3. src/backend/access/transam/xlog.c, routine CreateCheckPoint:
>> does this *entire* routine need to be a critical section? Again,
>> I fear a shotgun approach will mean a net decrease in reliability,
>> not an improvement. How much of this code r
> 1. src/backend/access/nbtree/nbtinsert.c, line 867: shouldn't this
> END_CRIT_SECTION be moved up to before the _bt_wrtbuf call? It seems
> to me that an elog during the wrtbuf is not a critical failure. If
> this code is correct, then all the other crit sections are wrong,
> because all of th
Tom Lane writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > perhaps
> > #define IsA_Value(t) \
> > (IsA(t, Integer) || IsA(t, Float) || IsA(t, String))
> > should be augmented with BitString. Can someone advise?
>
> Yes, definitely --- see the sole use of that macro, in outfuncs
OK, I will delete my copy of the email. If there is something to be
added to the TODO list, let me know.
[ People are welcome to modify it themselves too.]
> Bruce Momjian writes:
>
> > Any idea where we are on this?
>
> > > Bit and hexstring literals are not handled in a reasonable fashion;
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> perhaps
> #define IsA_Value(t) \
> (IsA(t, Integer) || IsA(t, Float) || IsA(t, String))
> should be augmented with BitString. Can someone advise?
Yes, definitely --- see the sole use of that macro, in outfuncs.c.
This is a bug.
Bruce Momjian writes:
> Any idea where we are on this?
> > Bit and hexstring literals are not handled in a reasonable fashion;
Bit string literals are handled correctly, although it occurred to me that
perhaps
#define IsA_Value(t) \
(IsA(t, Integer) || IsA(t, Float) || IsA(t, String))
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> More importantly, you *should* *not* do these tests in configure because
> these tests will be unreliable in a cross-compilation situation.
> Cross-compilation in this context does not only mean compiling between
> completely different platforms, but
Thomas Lockhart writes:
> I'm not sure I fully appreciate the distinction here. configure will
> check for "behavior" of various kinds, including "behavior assumptions"
> in the PostgreSQL code.
There are two general categories of platform dependencies: One is
compilation system features, for e
Any idea where we are on this?
> Can we get the BIT type working now that 7.1 is branched?
>
> I did some work on the BIT types a couple months ago. According to
> my notes, the following issues are still outstanding before they
> can be said to work at all:
>
> Bit and hexstring literal
Any idea if this is fixed?
> Bruce Momjian writes:
>
> > Peter, comments?
>
> It doesn't destroy all databases anymore, although I can't make any
> statements about what it actually does do. I suppose it's still broken.
>
> > > Richard Poole <[EMAIL PROTECTED]> writes:
> > > > It seems that
El Vie 19 Ene 2001 17:36, Len Morgan escribió:
> > pga_forms | table | postgres
> > pga_queries | table | postgres
> > pga_reports | table | postgres
> > pga_schema | table | postgres
> > pga_scripts | table | postgres
> >(8 rows)
> >
> >
> >Any ideas why those pg* tables ar
> > Okay, so you call mktime with a pre-1970 date once when the system starts
> > up or when the particular function is first used and then save the result
> > in a static variable.
> Can anybody else give an OK to this approach, that affects all platforms ?
> I am not convinced, that this is the
> The __asm___ and splitting up the assembly code into multiple string
> literals and the consistent formatting of the register addendums are
> all fine, because those are read by gcc and this whole code block is
> gcc-only. But the assembly code string literal will be spit out
> essentially verb
> Exactly. What if someone has a binary PostgreSQL package installed, then
> updates his time library to something supposedly binary compatible and
> finds out that PostgreSQL still doesn't use the enhanced capabilities?
> Runtime behaviour checks are done at runtime, it's as simple as that.
I'm
Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I believe the formatting problem was that some code had
> > > "command;command; : lkjasfd : asldfk" while some had them spread over
> > > separate lines, and others used \n\, all very randomly. Now at l
I had to re-compile and re-install postgresql-7.1-beta1.
I changed the directory where it was installed from /usr/local/pgsql to
/dbs/postgres/. After re-installing I copied the data/ directory that was
under the old instalation to where I have the new instalation.
After a bit of work I got it t
Patrick Welche writes:
> Just tried it for the first time:
> % cd src/test/locale
> % gmake all
> gmake: Circular test-pgsql-locale <- all dependency dropped.
> cd: can't cd to pgsql-locale
> gmake: *** [test-pgsql-locale] Error 2
I think it should work now.
--
Peter Eisentraut [EMAIL PRO
Got it. Corrected TODO.detail.
[ Charset ISO-8859-1 unsupported, converting... ]
> > So, we probably should put new free dirty buffer just before first
> > undirty one in LRU.
>
> Ops - new free UNdirty buffer before first DIRTY one in LRU,
> sorry -:)
>
> Vadim
>
--
Bruce Momjian
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Interestingly, we have very few non-gcc ASM entries in s_lock.h. The
> only non-gcc one I see are Univel/i386, and I didn't touch that. Isn't
> the semicolon the standard command terminator for all gcc assemblers?
No.
It is for most, but not for the
On Fri, Jan 19, 2001 at 12:03:58PM -0500, Bruce Momjian wrote:
>
> Tom, did we ever test this? I think we did and found that it was the
> same or worse, right?
(Funnily enough, I just read that message:)
To: Bruce Momjian <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Possibl
* Tom Lane <[EMAIL PROTECTED]> [010119 13:08]:
>
> > Oh, wow, I never suspected gcc could work without gas. Can it?
>
> Gcc with platform-specific as used to be the standard configuration
> on HPUX, and may still be standard on some platforms.
Still is the standard on UnixWare with GCC. The st
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I believe the formatting problem was that some code had
> > "command;command; : lkjasfd : asldfk" while some had them spread over
> > separate lines, and others used \n\, all very randomly. Now at least
> > they are all consistent and use similar fo
> So, we probably should put new free dirty buffer just before first
> undirty one in LRU.
Ops - new free UNdirty buffer before first DIRTY one in LRU,
sorry -:)
Vadim
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I believe the formatting problem was that some code had
> > "command;command; : lkjasfd : asldfk" while some had them spread over
> > separate lines, and others used \n\, all very randomly. Now at least
> > they are all consistent and use similar fo
Trond Kjernaasen <[EMAIL PROTECTED]> writes:
> Sorry for posting followups on my own mails, but I've noticed that
> I can actually use lo_read() if I read the BLOBs in chunks of
> 32760 bytes. If I try to read 32761 bytes it fails for some reason.
I'm betting that something is rounding up to the
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> And they may all be broken, except for the one(s) you have tested.
>> You shouldn't be assuming that a platform that uses gcc necessarily
>> also uses gas.
> I can tell you that they all used __asm__, and all used the colon
> terminators for each __asm
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Bruce Momjian writes:
> >> In looking at the VAX ASM problem, I realized that the ASM in s_lock.h
> >> is all formatted differently, making it even more confusing. I have
> >> applied the following patch to s_lock.h to try and clean it up.
>
> >
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I believe the formatting problem was that some code had
> "command;command; : lkjasfd : asldfk" while some had them spread over
> separate lines, and others used \n\, all very randomly. Now at least
> they are all consistent and use similar formatting.
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>> In looking at the VAX ASM problem, I realized that the ASM in s_lock.h
>> is all formatted differently, making it even more confusing. I have
>> applied the following patch to s_lock.h to try and clean it up.
> I don't belie
> > Tom, did we ever test this? I think we did and found that
> > it was the same or worse, right?
>
> I tried it and didn't see any noticeable improvement on the particular
> test case I was using, so I got discouraged and didn't pursue the idea
> further. I'd like to come back to it someday,
I will throw the email into the optimizer TODO.detail file.
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom, did we ever test this? I think we did and found that it was the
> > same or worse, right?
>
> I tried it and didn't see any noticeable improvement on the particular
> test case I wa
Threw it into TODO.detail performance, not optimizer.
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom, did we ever test this? I think we did and found that it was the
> > same or worse, right?
>
> I tried it and didn't see any noticeable improvement on the particular
> test case I was usin
I added this too to TODO.detail/performance.
> On Fri, Jan 19, 2001 at 12:03:58PM -0500, Bruce Momjian wrote:
> >
> > Tom, did we ever test this? I think we did and found that it was the
> > same or worse, right?
>
> (Funnily enough, I just read that message:)
>
> To: Bruce Momjian <[EMAIL PR
Due to a number of interrelated factors, the 7.1beta3-2 source rpm will
likely not build properly on any build machine in its present state. It
wil build just fine on mine -- but mine isn't exactly 'clean' in the
sense that it has PostgreSQL 7.1beta3 RPMS _installed_ already.
I will be fixing t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, did we ever test this? I think we did and found that it was the
> same or worse, right?
I tried it and didn't see any noticeable improvement on the particular
test case I was using, so I got discouraged and didn't pursue the idea
further. I'd lik
Tom, did we ever test this? I think we did and found that it was the
same or worse, right?
> Those of you with long memories may recall a benchmark that Edmund Mergl
> drew our attention to back in May '99. That test showed extremely slow
> performance for updating a table with many indexes (a
On Fri, Jan 19, 2001 at 12:46:53AM +0100, Peter Eisentraut wrote:
> Tom Lane writes:
>
> > Gene and I looked into this, and the cause of the misbehavior is this:
> > gcc on this installation is set to search /usr/local/lib (along with the
> > usual system library directories). libz.so and librea
> Bruce Momjian writes:
>
> > In looking at the VAX ASM problem, I realized that the ASM in s_lock.h
> > is all formatted differently, making it even more confusing. I have
> > applied the following patch to s_lock.h to try and clean it up.
>
> I don't believe in this patch at all. It makes th
Sorry for posting followups on my own mails, but I've noticed that
I can actually use lo_read() if I read the BLOBs in chunks of
32760 bytes. If I try to read 32761 bytes it fails for some reason.
Thanks,
--
Trond K.
Trond Kjernaasen <[EMAIL PROTECTED]> writes:
> Hi,
>
> I've done some tes
> > We do not need any execution time checks for this at all. The objective is
> > to determine whether mktime works for any results that would be negative.
> > On AIX and IRIX all calls to mktime for dates before 1970 lead to a result of
> > -1, and the configure test is supposed to give a defin
Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Tom, try out a PPC build on this one. I know of one problem that I have
> > to fix -- postgresql-perl fails dependencies for libpq.so (I backed out
> > the patch to Makefile.shlib).
> The backend seems to build OK, but the build fails
> > I agree that configure is the way to go. What if someone has
> > installed a third party library to provide a better mktime() and
> > localtime()?
>
> Exactly. What if someone has a binary PostgreSQL package installed, then
> updates his time library to something supposedly binary compatib
Zeugswetter Andreas SB writes:
> We do not need any execution time checks for this at all. The objective is
> to determine whether mktime works for any results that would be negative.
> On AIX and IRIX all calls to mktime for dates before 1970 lead to a result of
> -1, and the configure test is s
Pete Forman writes:
> I agree that configure is the way to go. What if someone has
> installed a third party library to provide a better mktime() and
> localtime()?
Exactly. What if someone has a binary PostgreSQL package installed, then
updates his time library to something supposedly binary
Thanks. Applied. (Tom already approved it.)
> Attached.
>
> Tom Lane ([EMAIL PROTECTED]) wrote:
>
> > Travis Bauer <[EMAIL PROTECTED]> writes:
> > > I have attached a simple change to src/pl/plperl/plperl.c to
> > > enable the :bash_math opcodes. Currently plperl.c only
> > > enables the :
Bruce Momjian writes:
> In looking at the VAX ASM problem, I realized that the ASM in s_lock.h
> is all formatted differently, making it even more confusing. I have
> applied the following patch to s_lock.h to try and clean it up.
I don't believe in this patch at all. It makes the assumption t
On Fri, Jan 19, 2001 at 10:29:15AM -0500, Tom Lane wrote:
> Did you get the update I made on 1/14 to #include "postgres.h" at the
> head of pgc.l ?
No, that one is missing. Thanks. I'll add it immediately.
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Li
"Heinz Ekker" <[EMAIL PROTECTED]> writes:
> In my setup, which is RedHat 7.0, libc-2.2, glibc 2.96 (yes, the bad one)
> and perl 5.6.0 with DBI-1.14 and DBD-Pg-0.95 libpq.so.2.1 segfaults due to
> a null pointer dereference in printfPQExpBuffer.
> (gdb) bt
> #0 _IO_vsnprintf (string=0x0, maxlen=
Michael Meskes <[EMAIL PROTECTED]> writes:
> Seems to work fine here. But it's pgc.c that does not work anymore:
> gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations
> -I../../../../src/include -I./../include -DMAJOR_VERSION=2 -DMINOR_VERSION=8
> -DPATCHLEVEL=0 -DINCLUDE_PATH=\"/usr/local/
Patrick Welche <[EMAIL PROTECTED]> writes:
> Wouldn't a -Wl,-R/usr/local/lib have helped?
Well, yeah, but how would we know to do that? The fact that gcc is
searching /usr/local/lib is completely unknown to configure.
regards, tom lane
I`mtrying to make a select which envolves two tables with in a
functionif the query is written this way: (this is just an example,
not my query)
a := (select count(*) from xx);
it works fine, but if I type the query like this
select count(*) from xx;
it throws a message that says unexpecte
From: Maneerat Sappaso <[EMAIL PROTECTED]>
Subject: install locale.
Date: Fri, 19 Jan 2001 17:40:56 -0700 (GMT)
Message-ID: <[EMAIL PROTECTED]>
>
> Deer sir,
>
> I found something wrong when I test program in
> /usr/src/test/locale/test-pgsql-locale.c
> It s
Hi,
I've done some tests with large objects and it works just fine under
Linux, but when I try the same code under Windows (I use the libpq
frontend) it fails for some reason with lo_read() always returning 0.
The test program I'm using is basically a modified version of the one
listed in chapt
El Jue 18 Ene 2001 15:15, Tom Lane escribió:
>
> > The other question is if I have to do something special (dump and
> > restore) when upgrading from 7.1-beta1 to 7.1-final (or any of the other
> > betas)?
>
> You will need an initdb to go from beta1 to beta3. Sorry about that;
> we try to avoid
Hi all,
if this is already known, I'm sorry. My search in the Mailing list archives
via the web interface yielded nothing.
In my setup, which is RedHat 7.0, libc-2.2, glibc 2.96 (yes, the bad one)
and perl 5.6.0 with DBI-1.14 and DBD-Pg-0.95 libpq.so.2.1 segfaults due to
a null pointer dereferen
Attached.
Tom Lane ([EMAIL PROTECTED]) wrote:
> Travis Bauer <[EMAIL PROTECTED]> writes:
> > I have attached a simple change to src/pl/plperl/plperl.c to
> > enable the :bash_math opcodes. Currently plperl.c only
> > enables the :default opcodes. This leave out about five of six
> > math fun
On Thu, Jan 18, 2001 at 01:58:20PM +, Thomas Lockhart wrote:
> I haven't been able to update my cvs sources for a few days, but on my
> machine preproc.y produces 321 shift/reduce errors. Does it still, or is
> that patched up?
Hmm, I never saw that:
postgres@feivel:~/pgsql/src/interfaces/ec
Tom Lane wrote:
>
>
> What I want to know is what's the difference between the "ANSI" and
> "ISO" PDF versions that ANSI sells, other than a factor of 15 in price?
> I sent an email inquiry about that to ANSI a month ago, and have not
> gotten an answer. Anyone know?
>
IIRC the SQL92 drafts had
Bruce Momjian wrote:
>
> Added to TODO:
>
> * Add SHOW command to see locale
I'd rather like it to be a function, as version() is, because SHOW
commands may not
play nice with other interfaces than psql.
(and it can first be included in ./contrib if it's too late for a
"feature" )
Ju
Rob van Nieuwkerk wrote:
>
>
> The problem query returns the *right* answer now !
> Turning LANG=en_US back on gives the old buggy behaviour.
>
> I know very little about this LANG, LOCALE etc. stuff.
> But for our application it is very important to support "weird" characters
> like "éőĺĘ ..."
> > > You don't need to put this check into configure, you can just
> > > do the check after mktime() is used.
> >
> > No, we need that info for the output functions that only use localtime.
> > The intent is, to not use DST before 1970 on platforms that don't have
> > mktime for dates before 197
77 matches
Mail list logo
