> > First of all it will not break lo_creat, lo_unlink for sure.
>
> lo_creat depends on inv_create followed by inv_close; your patch
> proposed to disable both of those outside transaction blocks.
> lo_unlink depends on inv_drop, which ditto. Your patch therefore
> restricts lo_creat and lo_unli
Denis Perchine <[EMAIL PROTECTED]> writes:
> First of all it will not break lo_creat, lo_unlink for sure.
lo_creat depends on inv_create followed by inv_close; your patch
proposed to disable both of those outside transaction blocks.
lo_unlink depends on inv_drop, which ditto. Your patch therefor
> > On Saturday 20 January 2001 10:05, you wrote:
> > > I just wanted to confirm that this patch was applied.
> >
> > Yes, it is. But the following patch is not applied. But I sure that it is
> > neccessary, otherwise we will get really strange errors (see discussion
> > in the thread).
> >
> > ht
Main open item is the handling of hex strings: they are still converted
to integers by default. They could be BLOBs or bit strings, and the SQL
standard gives no hint, so it is not clear what the solution should be.
The only other complaint has been on the output of bit strings. I
believe the cur
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Can people comment on the following patch that Dennis says is needed?
I object strongly. As given, this would break lo_creat, lo_unlink,
lo_import, and lo_export --- none of which need to be in a transaction
block --- not to mention possibly causing gr
Sorry, here is a clean version of the patch.
> > http://www.postgresql.org/mhonarc/pgsql-patches/2000-11/msg00013.html
>
> Can people comment on the following patch that Dennis says is needed?
> It prevents BLOB operations outside transactions. Dennis, can you
> explain why BLOB operations have
[ Charset KOI8-R unsupported, converting... ]
> On Saturday 20 January 2001 10:05, you wrote:
> > I just wanted to confirm that this patch was applied.
>
> Yes, it is. But the following patch is not applied. But I sure that it is
> neccessary, otherwise we will get really strange errors (see dis
[EMAIL PROTECTED] (Rob van Nieuwkerk) writes:
> But if anybody thinks that selects with LIKE on indexed columns with
> single-byte non-ASCII characters are working OK: they are not !! See my
> posting and following thread "7.0.3 reproduceable serious select error"
> from a couple of days ago.
Ye
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > Suppose a function using table t1 as its argument:
> > create table t1(...
> > create fuction f1(t1) returns...
> > And if I drop t1 then do pg_dump, I would got something like:
> > failed sanity check, type with oid 1905168 was not found
> > This
On Sun, 21 Jan 2001 00:25:17 + (UTC), Tom Lane <[EMAIL PROTECTED]> wrote:
>Juriy Goloveshkin <[EMAIL PROTECTED]> writes:
>> Hello, I didn't know pgsql-sources close,
>> so I wrote this code just as example of idea.
>> Can somebody review and make patch for pgsql?
>
>AFAICT this only deals with
What I've done to solve the immediate C++ problem is to take the
declaration of sys_nerr out of c.h entirely, and put it into the
two C modules that actually need it. However, I'm still wondering
whether we should not drop the rangecheck on errno completely.
One interesting thing I discovered wh
Juriy Goloveshkin <[EMAIL PROTECTED]> writes:
> Hello, I didn't know pgsql-sources close,
> so I wrote this code just as example of idea.
> Can somebody review and make patch for pgsql?
AFAICT this only deals with the issue of single-byte characters that
sort in an order different from their nume
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > This would seem to be the right answer, but unfortunately Autoconf is not
> > > smart enough to detect marginal cross-compilation cases in all situations.
> > > Someone had zlib installed in a location where gcc would find it (compiles
> > > okay
Hello, I didn't know pgsql-sources close,
so I wrote this code just as example of idea.
Can somebody review and make patch for pgsql?
(if this idea is good, of cource).
like-optimization is working only with ASCII, but it is simple to fix.
This programm makes greater string(I tested with KOI8-R):
Frank Joerdens <[EMAIL PROTECTED]> writes:
> I haven't tried everything to recover from this yet, but will quickly
> try to document the crash before I lose track of what exactly went
> into it and what I did: Basically I deleted a table and then ran
> vacuum verbose, with the net result that I ca
I haven't tried everything to recover from this yet, but will quickly try to document
the
crash before I lose track of what exactly went into it and what I did: Basically I
deleted
a table and then ran vacuum verbose, with the net result that I cannot connect to this
database anymore with the er
El Sáb 20 Ene 2001 18:43, Peter Eisentraut escribió:
> Martin A. Marques writes:
> > > > Any ideas why those pg* tables are there?
> > >
> > > Those are system tables created and used by pgAccess.
> >
> > They never apeared before.
>
> You probably never ran pgaccess before.
No, I used to run pga
Martin A. Marques writes:
> > > Any ideas why those pg* tables are there?
> >
> > Those are system tables created and used by pgAccess.
>
> They never apeared before.
You probably never ran pgaccess before.
> And by the way, I see all the system tables when looking at any database with
> pgacce
On Sat, 20 Jan 2001, Tom Lane wrote:
> > The problem with just moving your database to the new location is that
> > there are location dependencies built into it when you use initdb to
> > initialize it, so it's not reliable.
>
> AFAIK, there are *not* any location dependencies in a standard PG
>
On Sat, Jan 20, 2001 at 02:18:55PM -0500, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > libpq doesn't use it either, but it uses tons of strerror().
>
> And also there are quite a few places in the backend that use strerror()
> directly. This lack of consistency seems like a
"Brett W. McCoy" <[EMAIL PROTECTED]> writes:
> On Sat, 20 Jan 2001, Martin A. Marques wrote:
>> The problem was that the server got downgraded from Solaris 8 to Solaris 7
>> and the binaries didn't work, so I recompiled. There was no way of using
>> pg_dump because I couldn't get the postmaster up
On Sat, 20 Jan 2001, Martin A. Marques wrote:
> > You probably should have used pg_dumpall to backup the databases and
> > restore them after the rebuild. That's a more reliable way of migrating
> > your data.
>
> The problem was that the server got downgraded from Solaris 8 to Solaris 7
> and t
El Vie 19 Ene 2001 22:32, Brett W. McCoy escribió:
> 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/ dir
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> libpq doesn't use it either, but it uses tons of strerror().
And also there are quite a few places in the backend that use strerror()
directly. This lack of consistency seems like another reason to forget
about testing errno against sys_nerr in elog
Tom Lane writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >> Er, what will you ifdef exactly,
>
> > + #ifdef __cplusplus
#ifndef, I meant. I.e., only declare it when in C, since libpq++ does not
use it. libpq doesn't use it either, but it uses tons of strerror().
Marko Kreen <[EMAIL PROTECTED]> writes:
> I can still reproduce it:
> marko=# SELECT 5 & ~6;
> ERROR: Unable to identify a right operator '&' for type 'int4'
> You may need to add parentheses or an explicit cast
Correct, we did not rejigger the operator precedence.
I played around with
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Er, what will you ifdef exactly,
> + #ifdef __cplusplus
> #ifdef HAVE_SYS_NERR
> extern int sys_nerr;
> #endif
> + #endif
>> and what are the odds that it will fail on some other platform?
> I don't see how it would fail.
Tom Lane writes:
> It occurs to me that the only likely use for initdb -t is now served by
> DROP DATABASE template1;
> CREATE DATABASE template1 WITH TEMPLATE = template0;
> ie, we have a *real* way to reconstruct a virgin template1 rather than
> an initdb kluge.
I agree.
> Accordi
Tom Lane writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> >> ../../../src/include/c.h:997: conflicting types for `int sys_nerr'
> >> /usr/include/stdio.h:224: previous declaration as `const int sys_nerr'
>
> > C++ apparently doesn't allow this, but C does. So you have to put #ifndef
> >
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> ../../../src/include/c.h:997: conflicting types for `int sys_nerr'
>> /usr/include/stdio.h:224: previous declaration as `const int sys_nerr'
> C++ apparently doesn't allow this, but C does. So you have to put #ifndef
> __cplusplus at the appropriat
Marko Kreen <[EMAIL PROTECTED]> writes:
> When will 64bit be a requirement?
As far as I'm concerned, it will *never* be a requirement,
at least not for the foreseeable future.
I do want the option to compile with 8-byte OID and/or XID types.
That's not a requirement.
reg
Tatsuo Ishii writes:
> 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/include/postgres.h:40,
> from pgconnection.h:41,
>
Ian Lance Taylor writes:
> > This would seem to be the right answer, but unfortunately Autoconf is not
> > smart enough to detect marginal cross-compilation cases in all situations.
> > Someone had zlib installed in a location where gcc would find it (compiles
> > okay) but the run-time linker wo
> > The first thought that comes to mind is that XIDs should be promoted to
> > eight bytes. However there are several practical problems with this:
> > * portability --- I don't believe long long int exists on all the
> > platforms we support.
> > regards, tom lane
How long
I think the XID wraparound matter might be handled a bit more simply.
Given a global variable X which is the earliest XID value in use at
some event (e.g. startup) you can compare two XIDs x and y, using
unsigned arithmetic, with just (x-X < y-X). This has the further
advantage that old transa
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> It is reported that building C++ interface on FreeBSD 4.2 fails.
> Can someone comment on this?
> In file included from ../../../src/include/postgres.h:40,
> from pgconnection.h:41,
> from pgconnection.cc:18:
> ../../../
36 matches
Mail list logo
