"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> On FreeBSD/Alpha, all 89 tests pass.
> I get this build warning though:
> gcc -pipe -O -Wall -Wmissing-prototypes -Wmissing-declarations -I. -I../../.
> ./src/include -c -o gram.o gram.c
> In file included from gram.y:7725:
> scan.l: In fun
GB Clark <[EMAIL PROTECTED]> writes:
> Well the subject says it all. It was there in the last beta I was testing
> which was beta 1.
AFAIR it was not in beta1 either. We've pushed perl5 and several other
modules out of the core distribution. They now have their own project
pages at gborg.postgre
On FreeBSD/Alpha, all 89 tests pass.
I get this build warning though:
gcc -pipe -O -Wall -Wmissing-prototypes -Wmissing-declarations -I. -I../../.
./src/include -c -o gram.o gram.c
In file included from gram.y:7725:
scan.l: In function `yyerror':
scan.l:583: warning: int format, different type
Further update:
I ran a test and compared the sizes of the postgres binary: 2926925
with palloc0, 2931293 without, a 0.14% decrease. Not very much,
considering the 1-14% speedup of MemSet with a constant.
Tom, I really didn't think those conditional tests would be significant,
but clearly they
Hello,
Well the subject says it all. It was there in the last beta I was testing
which was beta 1.
Am I being dense here, or is it really missing?
Thanks,
GB
--
GB Clark II | Roaming FreeBSD Admin
[EMAIL PROTECTED] | General Geek
CTHULU for President - Why choose the l
OK, my compiler, gcc 2.95 does the optimization at -O2, so I ran the
tests here with the attached program, testing a constant of 256 and a
variable 'j' equal to 256.
I found a 1.7% slowdown with the variable compared to the constant.
The 256 value is rather large. For a length of 32, the differe
In the last episode of this long-running issue, we decided that life
would be better if we make small-enough integer constants be initially
typed as int2 rather than int4, and then auto-promote them up to int4
when necessary. This would solve problems with, for example,
SELECT ... WHERE sm
On Thu, Nov 07, 2002 at 10:44:25PM +, [EMAIL PROTECTED] wrote:
> I know Ansi C language and SQL. I want to embed a sql statement into a c
> source code. Would you please recommend me some web sites or tutorials
> regarding this subject.
> Thank you for your concern,
You should have no probl
Joe Conway <[EMAIL PROTECTED]> quotes:
> In the SQL92 standard, the optional keyword AS is just noise and can be
> omitted without affecting the meaning. The PostgreSQL parser requires this
> keyword when renaming output columns because the type extensibility features
> lead to parsing ambiguiti
snpe wrote:
work, but I think that AS in 'as cluse' is optional
Please comment.
See:
http://developer.postgresql.org/docs/postgres/sql-select.html
Near the bottom:
" SQL92
SELECT Clause
In the SQL92 standard, the optional keyword AS is just noise and can be
omitted without affecting the
On Sun, 2002-11-10 at 10:41, snpe wrote:
> Hello,
> Query :
>
> select id i
> from tab
>
> don't work in PostgreSQL
>
> I know that
>
> select id as i
> from tab
>
> work, but I think that AS in 'as cluse' is optional
Thats true. Section 7.11 has i
> > You could set up query logging in the backend and see what the offending
> > query is. It may still be something you did (a missing or extra
> > something somewhere).
> >
> How ?
These settings have worked for me in a similar situation: (pulled from the
admin list archives)
My goal was to g
"Iavor Raytchev" <[EMAIL PROTECTED]> writes:
> Before the crash is this one -
> FATAL 1: Sorry, too many clients already
That should be harmless --- I doubt it's relevant to the crash, unless
you have timestamps that prove it happened just before the crash.
> IpcSemaphoreLock: semop(id=-1) failed
Hello,
Query :
select id i
from tab
don't work in PostgreSQL
I know that
select id as i
from tab
work, but I think that AS in 'as cluse' is optional
Please comment.
regards
Haris Peco
---(end of broadcast)
Tom,
Before the crash is this one -
FATAL 1: Sorry, too many clients already
Then there is a mixture of three messages -
IpcSemaphoreLock: semop(id=-1) failed: Invalid argument
DEBUG: pq_flush: send() failed: Bad file descriptor
NOTICE: Message from PostgreSQL backend:
The Postmaster has info
"Iavor Raytchev" <[EMAIL PROTECTED]> writes:
> -bash-2.05b$ psql
> psql: FATAL 1: The database system is in recovery mode
What do you find in the postmaster's log?
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'ki
On Sunday 10 November 2002 08:51 am, Hannu Krosing wrote:
> snpe kirjutas L, 09.11.2002 kell 22:51:
> > Hello,
> > I work with JDeveloper and PostgreSQL JDBC and I have one problem.
> > I get error :
> > sub-SELECT in FORM must have an alias
> > I can't change SQL command, but it is internal J
On Sunday 10 November 2002 05:27 am, Tom Lane wrote:
> snpe <[EMAIL PROTECTED]> writes:
> > I work with JDeveloper and PostgreSQL JDBC and I have one problem.
> > I get error :
> > sub-SELECT in FORM must have an alias
> >
> > Is it SQL standard (must have alias) or PostgreSQL specific ?
>
> T
Forgot to mention -
Free BSD 4.6.2
PostgreSQL 7.2.2
- Original Message -
From: "Iavor Raytchev" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, November 10, 2002 1:52 PM
Subject: The database system is in recovery mode
> Hello,
>
> We just crashed a live server with a load tes
Hello,
We just crashed a live server with a load tester. PostgreSQL tells -
-bash-2.05b$ psql
psql: FATAL 1: The database system is in recovery mode
We searched the documentation and the mailing lists, but we could not find
any instructions what to do in this case.
Shall we wait? Is a restart
snpe kirjutas L, 09.11.2002 kell 22:51:
> Hello,
> I work with JDeveloper and PostgreSQL JDBC and I have one problem.
> I get error :
> sub-SELECT in FORM must have an alias
> I can't change SQL command, but it is internal JDeveloper command
You could set up query logging in the backend and s
21 matches
Mail list logo
