The Bricolage developers are pleased to announce the release of
Bricolage version 1.3.3!
This the release candidate for Bricolage verion 1.4.0, and is
considered feature-complete. Nearly 50 new features have been added
since the 1.2.2 release, and over 80 bugs fixed. Barring any unforseen
maj
On Sun, 25 Aug 2002, Mark Stosberg wrote:
> Thanks for the clarification. Here's an idea about how to solve your
> problem. As you are importing your data, instead of doing it all at
> once, try import it a row at a time into a table that has the RI turned
> on. Check each insert to see if it's s
I found this email from April. It properly points out that our
LIMIT/FOR UPDATE ordering doesn't match MySQL's, and MySQL's looks more
correct, specifically that the FOR UPDATE is after the LIMIT. Our
grammar is:
| select_clause sort_clause opt_for_update_clause opt_select_limit
How do
On Mon, 19 Aug 2002, Stephan Szabo wrote:
> On Mon, 19 Aug 2002, Jiaqing wrote:
>
> > Hello,
> > I'm still new here and new to PostgreSQL, I'd like to know that after I
> > have created two databases on my site, such as one is called backend, and
> > another one is called admin, how do I refer(qu
On Sun, 25 Aug 2002, Andreas Tille wrote:
> On Sat, 24 Aug 2002, Mark Stosberg wrote:
>
> > On Thu, 22 Aug 2002, Andreas Tille wrote:
> > > Hello,
> > >
> > > I want to solve the following problem:
> > >
> > > CREATE TABLE Ref( Id int ) ;
> > > CREATE TABLE Import ( Idint,
> > >
On Sat, 24 Aug 2002, Mark Stosberg wrote:
> On Thu, 22 Aug 2002, Andreas Tille wrote:
> > Hello,
> >
> > I want to solve the following problem:
> >
> > CREATE TABLE Ref( Id int ) ;
> > CREATE TABLE Import ( Idint,
> > Other varchar(42),
> > Flag
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> It seems that when comparing char with text, the comparision is done
> as text, not as bpchar.
Yup. Arguably this is a bad idea: the system ought to reject the
comparison entirely, and make you cast one side or the other so that
it's clear to all c
Manuel Sugawara <[EMAIL PROTECTED]> writes:
> Ouch, 3117.48 msec vs. 1.15 msec is a huge difference. I need
> something else? or may be postgres optimizer can't cope with
> left/right joins?
I think the problem is you're constraining the join order into a very
inefficient one. See
http://www.ca
Ross J. Reedstrom wrote:
> On Sat, Aug 24, 2002 at 10:56:31PM -0700, Jiaqing Wang wrote:
> > Hello,
> >
> > I found below situation weird, it seems to me a bug.
> >
> > backend=> select * from valid_addr where state_abrev=upper('pr');
> > zip_code | city_name | state_abrev
> > --+---
