Re: [BUGS] to_date() month translation

2001-06-18 Thread Karel Zak

On Fri, Jun 15, 2001 at 04:51:26PM -0400, [EMAIL PROTECTED] wrote:

> Sample 1:
> -
> 
> template1=# select to_date('12-January-2001','DD-Month-');
>   to_date
> 
>  0001-01-12
> (1 row)
> 
> template1=# select to_date('12-January  -2001','DD-Month-');
>   to_date
> 
>  2001-01-12
> (1 row)
> 
> No file was uploaded with this report


 What is bad on the PostgreSQL documentation and mailing list archives?!

The month name string is 9-chars or you must use FM (fill-mode)option:

test=# select to_char(now(), 'Month DD');
   to_char
--
 June  18
(1 row)

test=# select to_char(now(), 'FMMonth DD');
 to_char
-
 June 18
(1 row)

test=# select to_date('12-January-2001','DD-FMMonth-');
  to_date

 2001-01-12
(1 row)

Karel

-- 
 Karel Zak  <[EMAIL PROTECTED]>
 http://home.zf.jcu.cz/~zakkr/
 
 C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



RE: [BUGS] Referential integrity problem

2001-06-18 Thread Patti Morgan

Please take my name off of this email list.

Thank you!

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 18, 2001 12:49 PM
To: [EMAIL PROTECTED]
Subject: [BUGS] Referential integrity problem


Denis Sbragion ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.

Short Description
Referential integrity problem

Long Description
It looks like performing operation in two steps on tables with multiple
deferred referential integrity constraints between them is not allowed. Not
sure this is a bug, may be it is required by the standards, but sure it is
rater counterintuitive (may be, of course, I'm completely wrong). Most of
the times this is just annoying, sometimes it doesn't let you do updates,
i.e. whenever you cannot perform the update in a single step (I found at
least one case). Tested both on 7.0.3 and 7.1.2, with same results.

P.S. Great job guys. 7.0.3 was very good, but 7.1.2 is simply wonderful.

Sample Code
Here it is an oversimplyfied example:

create table tablea
 (
  fielda integer,
  fieldb varchar(128),
  constraint tablea_pkey primary key (fielda)
 );

create table tableb
 (
  fielda integer,
  fieldb integer,
  fieldc varchar(128),
  fieldd integer,
  constraint tableb_pkey primary key (fielda, fieldb),
  constraint tablea_to_tableb foreign key (fielda) references
   tablea (fielda) on delete restrict on update restrict
   deferrable initially deferred,
  constraint scndtablea_to_tableb foreign key (fieldd) references
   tablea (fielda) on delete restrict on update restrict
   deferrable initially deferred
 );

insert into tablea (fielda, fieldb) values (1, 'Key 1');
insert into tableb (fielda, fieldb, fieldc, fieldd) values (1, 1, 'Ref to
Key 1', 1);

Performing:

begin;
update tableb set fielda = 2, fieldd = 2 where fielda = 1;
update tablea set fielda = 2 where fielda = 1;
commit;

it's ok as it should. If you do the same thing above (now reversed, of
course) in two steps, i.e:

begin;
update tableb set fielda = 1 where fielda = 2;
update tableb set fieldd = 1 where fieldd = 2;
update tablea set fielda = 1 where fielda = 2;
commit;

gives:

ERROR:  scndtablea_to_tableb referential integrity violation - key
referenced from tableb not found in tablea

I hope it's clear.

No file was uploaded with this report


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [BUGS] Referential integrity problem

2001-06-18 Thread Stephan Szabo

On Mon, 18 Jun 2001 [EMAIL PROTECTED] wrote:

> Denis Sbragion ([EMAIL PROTECTED]) reports a bug with a severity of 3
> The lower the number the more severe it is.
> 
> Short Description
> Referential integrity problem
> 
> Long Description It looks like performing operation in two steps on
> tables with multiple deferred referential integrity constraints
> between them is not allowed. Not sure this is a bug, may be it is
> required by the standards, but sure it is rater counterintuitive (may
> be, of course, I'm completely wrong). Most of the times this is just
> annoying, sometimes it doesn't let you do updates, i.e. whenever you
> cannot perform the update in a single step (I found at least one
> case). Tested both on 7.0.3 and 7.1.2, with same results.
> 
> P.S. Great job guys. 7.0.3 was very good, but 7.1.2 is simply wonderful.

Yep.  AFAICT it's currently broken for such cases.  I've been working
(slowly :() on fixing it so it doesn't try the checks on rows that are no
longer valid (such as the intermediate states of multiple updates).



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster