On Wed, May 14, 2008 at 07:06:03PM +, Francisco Leovey wrote:
if you write
EXEC SQL SET datestyle TO SQL, DMY;
you get ERROR: syntax error at or near SQL
But
EXEC SQL SET datestyle TO Postgres, DMY;
works fine
Thanks for the report. I fixed it in CVS for 8.2, 8.3 and HEAD.
The following bug has been logged online:
Bug reference: 4219
Logged by: Nathan Reed
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: Sparc Solaris 10 - 08/07 release
Description:fseeko test failure in configure script
Details:
It does
Nathan Reed wrote:
The following bug has been logged online:
Bug reference: 4219
Logged by: Nathan Reed
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: Sparc Solaris 10 - 08/07 release
Description:fseeko test failure in configure script
Nathan Reed [EMAIL PROTECTED] writes:
It does not matter what parameters I do or do not provide on the configure
step, I get the same failure every time:
checking for fseeko... (cached) yes
checking test program... failed
configure: error:
Could not execute a simple test program. This may
The following bug has been logged online:
Bug reference: 4220
Logged by: Lon Varscsak
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: Linux (RHEL 5)
Description:delete statement deleted too many rows
Details:
I executed this query:
On Wed, Jun 04, 2008 at 06:46:42PM +, Lon Varscsak wrote:
delete from customer_transactions_detail where transaction_id in (select
transaction_id from test);
The transaction_id column does NOT exist in the temporary table named
'test'). I would think this would just result in an error,
hubert depesz lubaczewski [EMAIL PROTECTED] writes:
On Wed, Jun 04, 2008 at 06:46:42PM +, Lon Varscsak wrote:
delete from customer_transactions_detail where transaction_id in (select
transaction_id from test);
The transaction_id column does NOT exist in the temporary table named
'test').
I looked at the config.log file, but I can only discern that it
appears to be failing on fseeko in the configure section that loops
through tests in the area where there are comments about NetBSD, etc
re-rendering of fseeko. Understanding that make is difficult with
messaging, the output that
I am using the gcc 3.4.6 compiler. With all of the needed packages
for this config run, I have included the following elements in a script:
#
./configure --with-openssl --with-libxml --with-libxslt
--with-libraries=/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.2/lib
Wow, I want it to violate the spec so I can get my rows back! :)
I understand the problem and why it did what it did now though.
Thanks for your help,
Lon
On Wed, Jun 4, 2008 at 1:08 PM, Tom Lane [EMAIL PROTECTED] wrote:
hubert depesz lubaczewski [EMAIL PROTECTED] writes:
On Wed, Jun 04,
Nathan Reed [EMAIL PROTECTED] writes:
I looked at the config.log file, but I can only discern that it
appears to be failing on fseeko in the configure section that loops
through tests in the area where there are comments about NetBSD, etc
re-rendering of fseeko.
Well, if you don't
The following bug has been logged online:
Bug reference: 4222
Logged by: Parag Goyal
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: Window XP
Description:ERROR: cache lookup failed for relation
Details:
ERROR: Cache lookup failed for
Parag Goyal wrote:
ERROR: Cache lookup failed for relation incurred
and we are not able to fire any query for the particular relation any
more(table).
ERROR: Cache lookup failed for relation
even we are not able to delete the particular schema.
Please copy-paste and post the actual queries
13 matches
Mail list logo
