I have updated the documentation on encodings to more closely match our
code, added descriptions, and a list of aliases for encodings. I also
reorderd the lists to they were alphabetical. Look here to see the
results:
http://candle.pha.pa.us/main/writings/pgsql/sgml/multibyte.html
Comme
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> I want to descibe some strange behaviour of the postgres planner.
It's not strange exactly: the mechanism for OR indexscan and the
mechanism for nestloop join indexscan are separate and don't talk
to each other. So you don't get to have a join inn
Hi All,
I want to descibe some strange behaviour of the postgres planner.
I have 2 tables:
wsdb=# \d q3c
Table "public.q3c"
Column | Type | Modifiers
++---
ipix | bigint |
errbox | box|
ra | real |
dec| real |
Indexes:
"ipix_idx" b
Oleg Bartunov writes:
> REL8_0_STABLE:
> tycho=# select * from pg_stas where srelnae='tycho';
> tycho=# \q
Works fine for me in REL8_0_STABLE tip ... and it's working fine on all
the build farm machines too, because this would surely cause all the
regression tests to fail. Sure you didn't mistak
Oleg Bartunov wrote:
> On Sat, 12 Mar 2005, Bruce Momjian wrote:
>
> > Oleg Bartunov wrote:
> >> Hi there,
> >>
> >> I noticed client error logging was changed in REL8_0_STABLE in compare
> >> with
> >> 8.0.1 release.
> >>
> >> 8.0.1:
> >> tycho=# select * from pg_stas where srelnae='tycho';
> >
On Sat, 12 Mar 2005, Bruce Momjian wrote:
Oleg Bartunov wrote:
Hi there,
I noticed client error logging was changed in REL8_0_STABLE in compare with
8.0.1 release.
8.0.1:
tycho=# select * from pg_stas where srelnae='tycho';
ERROR: relation "pg_stas" does not exist
tycho=# \q
REL8_0_STABLE:
tycho=
Oleg Bartunov wrote:
> Hi there,
>
> I noticed client error logging was changed in REL8_0_STABLE in compare with
> 8.0.1 release.
>
> 8.0.1:
> tycho=# select * from pg_stas where srelnae='tycho';
> ERROR: relation "pg_stas" does not exist
> tycho=# \q
>
> REL8_0_STABLE:
> tycho=# select * from
On Friday 11 March 2005 12:18, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > On Fri, Mar 11, 2005 at 11:32:04AM -0500, Bruce Momjian wrote:
> > > Chris Mair wrote:
> > > > Hello,
> > > >
> > > > I'd like to start working on the following TODO item:
> > > > Referential Integrity / Support trigger
Hi there,
I noticed client error logging was changed in REL8_0_STABLE in compare with
8.0.1 release.
8.0.1:
tycho=# select * from pg_stas where srelnae='tycho';
ERROR: relation "pg_stas" does not exist
tycho=# \q
REL8_0_STABLE:
tycho=# select * from pg_stas where srelnae='tycho';
tycho=# \q
ostgr
Resubmission of yesterday's patch so that it would
cont conflict with Bruce's cvs commit. Pleas apply.
Best regards,
Nicolai.
On Sat, 12 Mar 2005 01:58:15 +0200, Nicolai Tufar <[EMAIL PROTECTED]> wrote:
> On Thu, 10 Mar 2005 19:21:41 -0500 (EST), Bruce Momjian
> wrote:
> > > The CVS-tip impleme
Devrim GUNDUZ wrote:
On Sat, 12 Mar 2005, Joe Conway wrote:
Although listed as RH9, the ones at http://www.joeconway.com/ work on
my FC2 machine. They don't work on FC3 however, and I haven't gotten
around to trying to rebuild on FC3.
If anyone's interested, I've rebuilt the packages for RHEL ES
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Sat, 12 Mar 2005, Joe Conway wrote:
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
The PostgreSQL docs suggest that ftp.postgresql.org holds binary builds of
CVSup:
Is this still the case? (I couldn't see any cvsup binaries, but perhaps
Joe Conway said:
> Tom Lane wrote:
>> Neil Conway <[EMAIL PROTECTED]> writes:
>>
>>>The PostgreSQL docs suggest that ftp.postgresql.org holds binary
>>>builds of CVSup:
>>>Is this still the case? (I couldn't see any cvsup binaries, but
>>>perhaps they are well-hidden).
>>
>>
>> If they are still
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
The PostgreSQL docs suggest that ftp.postgresql.org holds binary builds
of CVSup:
Is this still the case? (I couldn't see any cvsup binaries, but perhaps
they are well-hidden).
If they are still there, they're probably exceedingly out of da
14 matches
Mail list logo