The situation is this:I have cygwin
with ( dll 1.3.2 ) and latest Postgresql 7.1.2 on Win 2000with SP1.I
use Java and JDBC to connect from a Windows to Postgresql server to do avery
simple select:select count(*) from table1; // returns count of 2It
works fine.Now I run this on 10 threads in
Hi,
I'm having this bug ramdonly, some time with a "vacuum analyze" goes
away but not always
here the info:
obelix3=> select version();
version
---
PostgreSQL 7.0.3 on i686-p
POSTGRESQL BUG REPORT TEMPLATE
Your name : Geoffrey Reedy
Your email address : [EMAIL P
The follwoing statement does not work:
create view testview (primary) as select 'true';
The error I get is:
ERROR: parser: parse error at or near "primary"
Using PostgerSQL 7.1 on linux redhat kernel 2.2.19 intel.
> Jefim Matskin
>
>
>
---(end of broadcast)-
Jefim Matskin <[EMAIL PROTECTED]> writes:
> The follwoing statement does not work:
> create view testview (primary) as select 'true';
> The error I get is:
> ERROR: parser: parse error at or near "primary"
This is not a bug --- the syntax of CREATE VIEW has no provision for a
column name lis
Felipe Alvarez Harnecker <[EMAIL PROTECTED]> writes:
> obelix3=> set datestyle=postgres,euro;
> SET VARIABLE
> obelix3=> select * from orden_visita where fecha_emision <= 'today'::date;
> ERROR: Bad date external representation '07-17-2001'
Since '07-17-2001' is *not* a valid date in Euro conve
> My problem is that the ErWin generates the following syntax
> create view [view name] ( [col1] , [col2] ) as select [s1], [s2] from
> [table name];
> and as far as I know this is SQL92.
(checks spec...) You're right, SQL92 does require this syntax. Okay,
I'll put it on the to-do list.
> I think we are in great shape now. Thanks. The elog() problem was
> because they didn't define FRONTEND in the compile.
>
> --
> Bruce Momjian| http://candle.pha.pa.us
> [EMAIL PROTECTED] | (610) 853-3000
> + If your life is a hard drive, | 8
Use DECIMAL type. We will remove MONEY in a upcoming release.
>
> POSTGRESQL BUG REPORT TEMPLATE
>
>
>
> Your name
Tom Lane writes:
> >> Well, beside the referential constraint issue ( that can be solved by
> >> hand ), the most frustrating is that queries like
> >> DELETE FROM table* where key = some_value
> >> Fails ( parser error ). ( UPDATE either )
>
> Not as of 7.1.
>
> re
> I'm having this bug ramdonly, some time with a "vacuum analyze" goes
> away but not always
Likely not related at all.
> obelix3=> set datestyle=postgres,us;
> SET VARIABLE
> obelix3=> select * from orden_visita where fecha_emision <= 'today'::date;
> numero | corredor | ejecutivo | remoto
Thomas Lockhart writes:
> > I'm having this bug ramdonly, some time with a "vacuum analyze" goes
> > away but not always
>
> Likely not related at all.
>
> > obelix3=> set datestyle=postgres,us;
> > SET VARIABLE
> > obelix3=> select * from orden_visita where fecha_emision <= 'today'::dat
On Sun, Jul 22, 2001 at 08:10:32PM +0900, Tatsuo Ishii wrote:
> Hum. Why don't you enable --enable-multibyte and
> --enable-unicode-conversion and set client_encoding to UNICODE? That
> would do a conversion from/to UTF-8 for Tcl 8.x (x > 9) clients?
You're right. Probably, this way correct enoug
13 matches
Mail list logo
