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 HEA
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 no
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
D
"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. T
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:
dele
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
>>
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
--with-includes=/usr/l
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
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 und
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 r
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 al
13 matches
Mail list logo
