On Wed, 27 Aug 2008, Daryl Joubert wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4380
> Logged by: Daryl Joubert
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.3.3
> Operating system: WinXP SP2
> Description:Comparison of OLD and N
On Tue, 9 Sep 2008, Kevin wrote:
> The following bug has been logged online:
>
> Bug reference: 4412
> Logged by: Kevin
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0.15
> Operating system: Gentoo Linux
> Description:Check constraints cannot be added to
On Thu, 5 Feb 2009, Eduard Deacoon wrote:
> For example:
> --- Function convert column to string with delimiter
> --- $1 - TABLE with COLUMN to convert
> --- $2 - COLUMN to convert
> --- $3 - COLUMN for WHERE CLAUSE
> --- $4 - WHERE value
> --- $5 - delimeter
> --- In fact: SELECT $2 FROM $1 WHERE
On Tue, 13 Oct 2009, dan wrote:
> Let's say I have a table t with 5 columns c1 NOT NULL, c2 NOT NULL, c3, c4,
> c5
> and I have a UNIQUE index on (c1, c2) (remember c1 and c2 have a not null
> constraint)
>
> When I run the query:
> select c1,c2 from t
>
> I expect the explain to say index scan; i
On Thu, 12 Nov 2009, artur saldanha wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5182
> Logged by: artur saldanha
> Email address: artur.salda...@gmail.com
> PostgreSQL version: 8.3.5
> Operating system: Fedora 64
> Description:query with de
INTO
::=
[]
| DEFAULT VALUES
::=
But, this may be a useful extension to allow, at least with the
existance of LIMIT.
Stephan Szabo
[EMAIL PROTECTED]
On Thu, 17 Aug 2000, Bob Rivoir wrote:
>
> Please enter a FULL description of y
updates as appropriate.
(If this isn't in the TODO list or FAQ yet, it probably
should be.)
Stephan Szabo
[EMAIL PROTECTED]
On Wed, 23 Aug 2000 [EMAIL PROTECTED] wrote:
> NAGY Andras ([EMAIL PROTECTED]) reports a bug with a severity of 3
> The lower the number the more severe it is.
On Tue, 22 Aug 2000 [EMAIL PROTECTED] wrote:
> James Aspnes ([EMAIL PROTECTED]) reports a bug with a severity of 2
> The lower the number the more severe it is.
>
> Short Description
> checking foreign keys requires write access
>
> Long Description
> In version 7.0.2, create tables A and B wh
This sounds like an enhancement, not a bug per-se. SQL92 seems
to say the below about searched update statements. What
was the error you got from your first query? (I'd guess
a parser error at t1?)
::=
UPDATE
SET
[ WHERE ]
Stephan Szabo
[EMAIL PROTECTED]
On Tue, 29 Aug 2000 [
On Wed, 30 Aug 2000 [EMAIL PROTECTED] wrote:
> Short Description
> referential integrity requires write permission to a table which only needs to be
>read
Yes, this is a known problem.
> And, why is the trigger trying to select WITH UPDATE? (locking?)
Yes, if you don't grab a row lock, anothe
Yes, right now references constraints require update
permissions on the table being referenced in order
to grab row level locks on it with SELECT FOR UPDATE.
Stephan Szabo
[EMAIL PROTECTED]
On Thu, 31 Aug 2000, Alexei E. Korneyev wrote
ncing column in R1 shall be equal to the value of the
corresponding referenced column in some row of the referenced
table.
Stephan Szabo
[EMAIL PROTECTED]
On Sat, 2 Sep 2000, Richard Ellis wrote:
> The submit button on the form located at
> http://www.postgresql.org/bugs/bugs.php?1 r
This is a known bug. Current sources will not crash, but will
instead fail the query (since they are still referencing the name).
By 7.2, the ri triggers should probably be following the oid
of the tables and columns and will be safe from renames.
Stephan Szabo
[EMAIL PROTECTED]
On Sat, 9 Sep
IIRC, ALTER TABLE ... DROP CONSTRAINT isn't implemented yet,
so that's going to fail in any case. ADD CONSTRAINT is implemented
for foreign keys (in 7.0) and should be implemented for check
constraints in 7.1.
Stephan Szabo
[EMAIL PROTECTED]
On Mon, 2 Oct 2000, Stuart Peters wrote:
> \connect - postgres
> CREATE TABLE "bug" (
> "title" text
> );
> COPY "bug" FROM stdin;
> abcdefghijklm
> nopqrstuvwxyz
> aeiou
> \.
>
>
>
> The following queries work as expected, EXCEPT for [2]. I believe
> that [2] and [3] should return
n cases of this).
Stephan Szabo
[EMAIL PROTECTED]
On Fri, 6 Oct 2000, Wendel Leibe wrote:
> I think I have found a bug with Postgres' permissions. I have combed
> through the documentation, but I haven't been able to find an explanation
> for the following problem.
>
>
This is a stupid garden variety bug and I'm not sure why I didn't catch
it previously. The patch included is against fairly current sources, but
it may apply cleanly against 7.0.2 as well.
On Fri, 6 Oct 2000, Vilson farias wrote:
> I found a irregular behavior with constraints.
>
> I can only
ing the implied
statement).
Stephan Szabo
[EMAIL PROTECTED]
On Sat, 14 Oct 2000, Bruce Momjian wrote:
> Can someone give me a good description of this for TODO?
>
> >
> > Yes, this is a known issue due to the fact that the
> > triggers use SPI and need to use SELECT ... FOR UP
on is whether or not that's useful and
correct.
Stephan Szabo
[EMAIL PROTECTED]
On Sat, 14 Oct 2000, Bruce Momjian wrote:
> Oh, OK. I will forget it.
>
> >
> > Actually Peter did a patch for this fairly recently I
> > believe. I haven't grabbed CVS recently
I think that's what it should be doing.
~ is a regexp search, and . is the any character match
special character.
If you're looking for an actual . you'll need to
double backslash escape it.
Stephan Szabo
[EMAIL PROTECTED]
On Thu, 26 Oct 2000 [EMAIL PROTECTED] wrote:
&
On Fri, 27 Oct 2000, Jessica Ord wrote:
> I would be grateful if any of you could provide me any information that you
> may have.
>
> I have written a perl program which runs fine on a machine that was using
> PostgreSQL 6.4.2. I setup another machine which was running PostgreSQL
> 6.5.3 bundl
> THE TEST
> Run 'psql', then enter the following except for the select statement
> output.
>
> ---BEGIN---
> create table test (name char, a int, b int);
> insert into test values ('x', 1, 2);
> select * from test;
> update test set a=3,b=a where name='x';
> insert into test values ('y', 1, 2);
Where are your postmaster logs going? (where is your startup redirecting
stdout and stderr). Those may have additional information.
Also, can you get a backtrace from the core file with gdb?
On Mon, 30 Oct 2000, S Shaffer wrote:
> Post for FREE via your newsreader at post.usenet.com
This is a known problem in 7.0.x. The insert/update
constrained table case should be fixed in 7.1.
You can get details about it in the mailing list archives.
Stephan Szabo
[EMAIL PROTECTED]
On Tue, 31 Oct 2000, David Orr wrote:
> Your name : Dave Orr
> Your email a
Known issue with no real workaround apart from giving update
permissions. Should be fixed for 7.1 if Peter Eisentraut's patch
is in.
On Mon, 27 Nov 2000 [EMAIL PROTECTED] wrote:
Won't have a full answer until I'm home, but figured I'd send something.
> Description: Run the psql script below to generate
> the following error:
> psql:bug.sql:54: ERROR:
> const
Okay. On current sources, this seems to work with only a few changes.
You need unique or primary key constraints on the columns being
referenced (this is part of the spec but was not checked in 7.0)
A couple of other things, currently constraints don't inherit very well.
So, you'd probably wan
> Hi.
>
> I use version from cvs.
>
> I want to have array of referencies to another table, so I do:
> cms=# create table a (a int primary key); create table b (b int[]
> references a);
> NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'a_pkey' for
> table 'a'
> CREATE
> NOTICE:
On Tue, 12 Dec 2000, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> >> 2) It should be error in *creation* of table if there is no comparasion
> >> operator for constrain check
>
> > Possibly, although it currently doesn't to allow you
On Tue, 12 Dec 2000, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> >> In fact, there's a good argument that we should require the two columns
> >> to have the exact same datatype.
>
> > I think the spec only requires them to be co
What version are you using? The sample code works for me
on current sources, three rows with the last one as 3|null|null
Stephan Szabo
[EMAIL PROTECTED]
On Fri, 15 Dec 2000 [EMAIL PROTECTED] wrote:
> Grzegorz Mucha ([EMAIL PROTECTED]) reports a bug with a severity of 2
> The low
This a known problem which is caused by subselects in check constraints.
Current sources seem to give an error message at create time:
ERROR: Cannot use subselect in CHECK clause
In general subselects in check constraints also may constrain tables
that the subselect mentions. In your case
On Sun, 14 Jan 2001, Michael Richards wrote:
> Hi.
>
> I'm using 7.0.3 and I've found a bug:
>
> create table test(value int4);
> create function testfunc(int4)
> RETURNS bool AS
> 'SELECT count(*)>0 AS RESULT FROM test where value= $1'
> language 'SQL';
>
> So I want this
On Sun, 14 Jan 2001, Michael Richards wrote:
> I do not understand how this can possibly be correct unless NULL is
> not permitted in a function.
>
> In one case, I've got:
> WHERE value= $1
> Which is called with NULL and therefore should be:
> WHERE value= NULL
> This fails.
Right, but value
IIRC, index functions can take multiple arguments, it's just that
they cannot take constants. I think the values must all be columns
of the tables. So for example, this should work (seems to at
least create on 7.1beta3):
create table aaa (a int, b int, c text);
create index blah on aaa(substr(c,
Under 7.0 you needed update permission on the referenced table to
grab the necessary locks. Under 7.1 you won't need this anymore.
On Thu, 8 Feb 2001, Mike Howard wrote:
> Briefly, I create two tables, one having a column which references the
> other and which implements cascade deletes and up
> It appears that the triggers were never updated to now refer to 'old'
> instead of to current_usage when it was renamed, but were still
> associated with 'old' for purposes of dropping them. (i presume this
> is because the triggers were attached to 'old' by oid, which didnt
> change when it wa
On Wed, 21 Mar 2001, Romolo Manfredini wrote:
> Dear postgresql developers,
> I have found a small annoying bug in the SQL parser,
>
> executing the following query;
>
> select * from table where field ~* '*';
>
> or
>
> select * from table where field ~* '+';
>
> generate the following er
On Sun, 25 Mar 2001, Rolando Lora wrote:
> Hi there...
>
> I'm not sure if this is a "bug" or not but I couldn't
> find how to deal with it.
>
> For instance if we create a table using "Object ID"
> for storing large objects:
>
> > create table picture(id serial, pic_oid oid);
>
> and then we
This should be fixed for 7.1, it now checks that the
referencing columns exist on the fk table and that the
referenced columns are part of a unique index
[our unique/pkey] on the referenced table.
On Tue, 27 Mar 2001, Cid R Andrade wrote:
> PostgreSQL Developers,
>
> I have a PostgreSQL 7.0.2
> I am not sure whether this is a bug or a tightening-up of a previous
> loose SQL definition.
> Previously, I was able to define constraints that refer to the same
> table within the table itself,
> like so:
>
> CREATE SEQUENCE incidents_id_seq;
> GRANT ALL ON incidents_id_seq TO its;
> CREAT
On Fri, 13 Apr 2001 [EMAIL PROTECTED] wrote:
> Creating tables this way:
>
>A has a primary key
>B inherits A
>C references B
>
> results in an error message on the CREATE TABLE for C (ERROR: PRIMARY KEY for
>referenced table "b" not found).
>
> To reproduce:
>
> create table A
Known issue, see FAQ item 4.23. Short form, use exists rather
than in.
On Tue, 8 May 2001, [KOI8-R] þÅÒÅÐÁÎÏ× ìÅÏÎÉÄ wrote:
> Leonid ([EMAIL PROTECTED]) reports a bug with a severity of 2(?)
>
> Short Description
> Terrible perfomance during nested "... where x in (select ...)" operator
>
>
On Thu, 19 Apr 2001, Joseph Crawley wrote:
> I'm not sure if this is a bug or feature but in ver7.1 on linux you
> can't have a column name "primary".
Probably because it's a reserved word as part of PRIMARY KEY.
Actually if you double quote the name everywhere you use it, it'll
probably work,
On Wed, 16 May 2001 [EMAIL PROTECTED] wrote:
> Stephen Deasey ([EMAIL PROTECTED]) reports a bug with a severity of 2
> The lower the number the more severe it is.
>
> Short Description
> Foreign key constraints on inherited columns, 2 errors.
>
> Long Description
> Using the Postgres 7.1.1 RPMs
On Wed, 16 May 2001, Jonathan Ellis wrote:
> This is in 7.1.1:
>
> I was playing around with a table called user_comments and then dropped it.
> One of its columns referenced the user_id column of another table, users.
> Now whenever I try to update users, I get results like this:
> bf2-new=# up
On Wed, 16 May 2001, Jonathan Ellis wrote:
> > > Would manually
> > > removing it from pg_trigger cause Bad Things to happen?
> >
> > Yes, and you'll need to double quote the trigger name.
> > try
> > drop trigger "RI_ConstraintTrigger_44349" on users;
>
> That worked. Why was that?
It's a mix
On Sun, 20 May 2001 [EMAIL PROTECTED] wrote:
> Diego Saravia ([EMAIL PROTECTED]) reports a bug with a severity of 4
> The lower the number the more severe it is.
>
> Short Description
> references fail over rows inserted via inherited tables
>
> Long Description
> When you insert a row via an
On Sat, 2 Jun 2001, J. Michael Caine wrote:
> the following works:
>
> create table t1 (id serial primary key);
> create table t2 (id serial primary key);
> create table t12 (
> t1_id int references t1(id) on delete cascade,
> t2_id int references t2(id) on delete cascade
> );
>
> b
On Mon, 4 Jun 2001, Manager, RIKOP I.S.P. wrote:
> Dear Sir or Madam.
> We'we noticed that command
> psql -U user database
> don't check password. However databese was created next commad
> createdb -U user -W databese
What does your pg_hba.conf say?
---(end o
On Thu, 31 May 2001, Letitia Hickman wrote:
> Getting a "Warning: PostgreSQL query failed: ERROR: Cannot insert a
> duplicate key into unique index
> auditlog_pkey in /htdocs/ecorp-real-estate.com/intranet on line 167"
>
> Continue to get also
>
> :Warning: PostgreSQL query failed: ERROR: pars
I do not see this (using fairly random table
creations since you didn't provide the schema)
in 7.2devel. I get 7 and 7 at the end. Which
7.1 are you using? Have you tried upgrading
to 7.1.2?
In any case, a script to create the tables and
views and populate them with the appropriate data
wou
That's mostly because your c program is wrong. If you reorder the strings
you'll see that it's not sorting at all. It's just giving them back
in the order you gave them.
You should not compare the output from strcmp to -1. It's <0, 0, >0 not
-1, 0, 1. When I run the below program and add a p
On Mon, 11 Jun 2001, Michael Caine wrote:
> a month i was told that my possible bug submission was "sort of" a bug.
> the report and reply are below.
>
> now i write a follow up because i don't know how to establish a workroom.
> specifically, i know know that a unique constraint must be added
On Fri, 8 Jun 2001, kyle wrote:
> When specifying criteria in a where claue such as
> user_id = 'value' if a non-numeric is entered the
> query returns back all rows.
> user_id = user_id brings back every user_id instead of
> error because user_id is a numeric field and it
> shouldnt be able to
On Fri, 8 Jun 2001, meeta bhate wrote:
> Dear Sir,
> I am a Graduate student at the University of Toledo.My Master's project
> involves creating a database in PostgreSQL version 6.5.3.I was wondering
> if I can use SERIAL key along with a PRIMARY key as follows:
>
> create table ohiouniv (ui
On Thu, 14 Jun 2001 [EMAIL PROTECTED] wrote:
> Basil A. Evseenko ([EMAIL PROTECTED]) reports a bug with a severity of 3
> The lower the number the more severe it is.
>
> Short Description
> Strange CREATE VIEW behavior??
>
> Long Description
> createdb test
> psql test
>
> test=# create table
On Wed, 9 May 2001, Peter Eisentraut wrote:
> > Jerome O\'Neil ([EMAIL PROTECTED]) reports a bug with a severity of 2
>
> > SELECT updatability clause defective.
>
> Nope.
>
> > The syntax for select updatability clause is non-standard.
>
> That's not a bug.
>
> > While SQL-92 BNF describes
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
> tabl
On Sat, 23 Jun 2001, Micah Yoder wrote:
> Using PostgreSQL 7.1.2 compiled with Red Hat 7.1's gcc 2.96.
>
> I have a database that uses inherited tables. The top level table of the
> hierarchy has a serial column, which is the primary key. Everything inserted
> into any of its decendents and
On Fri, 6 Jul 2001 [EMAIL PROTECTED] wrote:
> José María Fernández González ([EMAIL PROTECTED]) reports a bug with a severity
>of 1
> The lower the number the more severe it is.
>
> Short Description
> Referential Integrity corrupted sometimes by Rules
>
> Long Description If you define an em
On Wed, 11 Jul 2001 [EMAIL PROTECTED] wrote:
> José María Fernández González ([EMAIL PROTECTED]) reports a bug
> with a severity of 2
> The lower the number the more severe it is.
>
> Short Description
> PL/pgSQL triggers with parameters don't work
>
> Long Description
> The report is fo
On Fri, 13 Jul 2001, Alexey V. Neyman wrote:
> Hello there!
>
> [Please Cc: me in followups.]
>
> I tried the following:
>
> CREATE TABLE a (
> int4 id
> );
> CREATE TABLE b (
> int4 id
> CHECK (id = ANY(SELECT a.id FROM a))
> );
>
> Tables are created ok, checking with '\d table' confi
Yes, it's because it sees the intermediate
state (6,1) when it shouldn't (it processes
each foreign key separately and does the cascade
update which places it in an "invalid" state
since the 1 key no longer exists).
I believe the fixes I've been working on for deferred
constraints will make this
On Thu, 19 Jul 2001 [EMAIL PROTECTED] wrote:
> Young ([EMAIL PROTECTED]) reports a bug with a severity of 2
> The lower the number the more severe it is.
>
> Short Description
> ERROR: CreateTrigger: function check_primary_key() does not exist
>
> Long Description
> I am using 7.1.2
>
> I alwa
More information to add to this bug.
I get the same behavior as the original poster, but the following on these
queries:
sszabo=> select myfloat-29.92 from "test_f4";
?column?
--
7.62939436071974e-08
7.62939436071974e-08
(2 rows)
sszabo=> select myfloat-'29.92
On Tue, 31 Jul 2001 [EMAIL PROTECTED] wrote:
> Rahul Gade ([EMAIL PROTECTED]) reports a bug with a severity of 1
Umm, 1? IIRC, order by in subqueries isn't even standard SQL, however
this should be taken care of in current sources so that you can use
order by ... limit in subqueries which soun
On Tue, 31 Jul 2001 [EMAIL PROTECTED] wrote:
> Christian Villa Real Lopes ([EMAIL PROTECTED]) reports a bug with a severity of 3
> The lower the number the more severe it is.
>
> Short Description
> ERROR: parser: parse error at or near "execute"
>
> Long Description I created a function to d
On Thu, 16 Aug 2001 [EMAIL PROTECTED] wrote:
> Laszlo Csite ([EMAIL PROTECTED]) reports a bug with a severity of 1
> The lower the number the more severe it is.
>
> Short Description
> inherited tables failure
>
> Long Description
> We have two tables inherited one from the other one. If you
On Fri, 17 Aug 2001, Pascal Bourguignon wrote:
>
> I've got the following problem with a plpgsql function. I believe it
> denotes a bug with plpgsql.
The problem is that you're trying to compare a space padded char
with a non-space padded text so it's not finding the row. I believe
This was a mistake in the interpretation of the spec (modification of
the same key row referenced by a foreign key constraint in the same
statement more than once is an error is how we believe the spec meant
it, but there's a case where they mention transaction and it got
misinterpreted). I don'
You probably need to run vacuum analyze after filling in the data.
Otherwise it's using bogus selectivity (see the number of expected
rows returned by the explain output, it's expecting 6000 rows after
the create index, which is large enough to make it guess that
it'll be cheaper to sequence scan
> Please enter a FULL description of your problem:
>
>
> Our development server, on occaision, runs out of swap space and
> inevitably when it does, the postmaster process stops. When restarted,
> the following info is in the log (the machine ran
On Mon, 3 Sep 2001, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > This was a mistake in the interpretation of the spec (modification of
> > the same key row referenced by a foreign key constraint in the same
> > statement more than once is an error
> Sample Code
> CREATE FUNCTION check_key(varchar,varchar) RETURNS OPAQUE AS '
> BEGIN
> IF COUNT(*) FROM $2 WHERE $2.$1=NEW.$1 THEN
>RAISE EXCEPTION ''integrity violation : duplicated key'';
> END IF;
> RETURN NEW;
> END;
> ' LANGUAGE 'plpgsql';
>
> CREATE TRIGGER trigger_
When I try your script on current sources I get an error about
the values being too long for the varchar(15) on some of the
inserts. My guess is that on the older version the varchar(15)
is truncating and making it different from the varchar(80) in
the referenced table so it really is a foreign
On Wed, 21 Nov 2001 [EMAIL PROTECTED] wrote:
> Edward Grabczewski ([EMAIL PROTECTED]) reports a bug with a severity
>of 1
> The lower the number the more severe it is.
>
> Short Description
> SERIAL type value not seen in FOREIGN KEY
>
> Long Description
> I have defined a table called arch_ob
On Mon, 24 Sep 2001, Ana Claudia wrote:
> Hello,
>
> Usually, I use Oracle for develop database application. However, I
> change my computer to Linux system (Mandrake 8) and I decide change database
> to Postgresql.
> In Oracle when I create a table where a colum is a char(n) or varchar(n), if
>
On Mon, 26 Nov 2001, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > As you see ONLY the 00CS ID is missplaced,
> > the others are in correct sequence! This isn't a locale specific
> > sort order. (I have RED HAT 7.1, with Hungarian settings,
>
> Still looks like locale to me. Exactl
On Mon, 26 Nov 2001, Tom Lane wrote:
> (HPUX is picky about locale names... 'hu_HU' doesn't work...)
> This doesn't seem to entirely square with the results you two get,
> but it sure does look like "CS" sorts in non-ASCII order in HU locale.
I tried it with the full locale name you used and so
On Tue, 27 Nov 2001, Sandor Vig wrote:
>
> > This doesn't seem to entirely square with the results you two get,
> > but it sure does look like "CS" sorts in non-ASCII order in HU locale.
>
> I've tried to understand the "bug" and I think I have something for you:
>
> The Hungarian ABC (traditiona
On Wed, 28 Nov 2001, Vicktor wrote:
> Hello All,
>
> Why not exists functions for convert any type to text?
> I can't find text(bool), text(numeric) ...
> May be it posiible in 7.2?
Don't think so. You need those functions and noone has written
them officially.
The former is easy, something
On Mon, 8 Oct 2001, BELLON Michel wrote:
> Hi all,
>
> Restoring a table with the following file
>
> <>
> I obtain the error
> ERROR: pg_atoi: error in "{{0.22,0.2,10 ... etc
> with INSERT INTO evtransftherm etc
>
>
> +--+
>
On Wed, 10 Oct 2001, Ralf Miller wrote:
> First question:
> The example shows that the column number of type serial is incremented
> as if the preceding insert-statement was successfull, even if it was
> not.
> Are the values for the column number of type serial inserted into the
> corresponding
On Wed, 17 Oct 2001 [EMAIL PROTECTED] wrote:
> Tony Tomov ([EMAIL PROTECTED]) reports a bug with a severity of 2
> The lower the number the more severe it is.
>
> Short Description
> strange behavior when creting rules with serial id
>
> Long Description
> I do not know if this is a bug, but f
On Fri, 30 Nov 2001 [EMAIL PROTECTED] wrote:
> > > So, it is still a mystery for me
> > You probably need the locale for sorting the single character letters
> > but you don't want the collation values of the multiple character ones.
> > I think you're probably going to need to get an alterna
On Thu, 29 Nov 2001, Kristian Lance wrote:
> The server is running:
>
> PostgreSQL version 7.0.2
> RedHat Linux 6.2
>
> When using ORDER BY in an SQL statement where the data type is varchar and
> the data are unix directory paths, the forward slashes (/) are ignored,
> causing the results to be
On Thu, 6 Dec 2001, Hao He wrote:
> hi,
>
> If you create a table with one of the columns defined as int8, then the
> index created on this column does not work. When I use explain to see
> the plan, it is always seq scan instead of index scan as one would expect.
> Other types of columns work f
> Now, Here's where things get weird.
>
> fdb=> explain SELECT count(*) FROM mfps_orderinfo_435 WHERE order_date =
> current_date;
> NOTICE: QUERY PLAN:
>
> Aggregate (cost=13532.12..13532.12 rows=1 width=0)
> -> Seq Scan on mfps_orderinfo_435 (cost=0.00..13528.77 rows=1340
> width=0)
On Thu, 13 Dec 2001 [EMAIL PROTECTED] wrote:
> Roger ([EMAIL PROTECTED]) reports a bug with a severity of 2
> The lower the number the more severe it is.
>
> Short Description
> In Red Hat don't open port 5432 and PostgreSql don't work.
>
> Long Description
> Hi!
> I recently installing Red Hat
On Fri, 14 Dec 2001 [EMAIL PROTECTED] wrote:
> Eugene Fokin ([EMAIL PROTECTED]) reports a bug with a severity of 2
> The lower the number the more severe it is.
>
> Short Description
> Unexpected DeadLock on REFERENCES
>
> Long Description
> DeadLock happens when we're trying to concurrent updat
On Sun, 16 Dec 2001 [EMAIL PROTECTED] wrote:
> luby liao ([EMAIL PROTECTED]) reports a bug with a severity of 2
> The lower the number the more severe it is.
>
> Short Description
> pg_dump a simple table can fail if other view/triggers are faulty
>
> Long Description
> We use Postgresql 7.1.2 o
On Wed, 9 Jan 2002, Mike Hoolehan wrote:
> Please enter a FULL description of your problem:
>
> if a quoted column alias in a FROM clause sub-select contains upper-case
> chars, then that column cannot be later referenced without using quotes
>
> P
On Wed, 9 Jan 2002, Bruno Wolff III wrote:
> I am seeing different results when using 'natural join' as opposed to
> 'join ... using' on what I think the equivalent columns should be.
> The 'join ... using' version of the query gives the expected answer.
> I have tried this on 7.1.3 (built local
On Tue, 29 Jan 2002 [EMAIL PROTECTED] wrote:
> Carlos Atencio ([EMAIL PROTECTED]) reports a bug with a severity of 2
>
> I've this query that I run in my app. For example, give a list of
> all sales from all my stores around the country. The query runs very
> fast and I get the result I want.
On Fri, 1 Feb 2002, hubert depesz lubaczewski wrote:
> Operating system:
> Linux (PLD), kernel 2.2.20
>
> Hardware:
> $ cat /proc/cpuinfo | grep -E "^(vendor_id|model name|cpu MHz)"
> vendor_id : GenuineIntel
> model name : Pentium III (Coppermine)
> cpu MHz : 871.474
>
> $ fr
On Tue, 29 Jan 2002, Nagasubramanya L wrote:
> I have even tried
> CREATE LANGUAGE 'plpgsql'
>
> But I am not able to set it. What is that I should do to set up this language
>support.
Use the shell script createlang
createlang plpgsql
should add it to the database in question.
On Fri, 8 Feb 2002 [EMAIL PROTECTED] wrote:
> 2. tables with complex foreign key constrains will not be imported
I probably couldn't help with the other question, but...
What do you mean by this? Does it error on the creation, does it
make the tables but not the constraints?
---
On Mon, 11 Feb 2002 [EMAIL PROTECTED] wrote:
> BAZIN Nicolas ([EMAIL PROTECTED]) reports a bug with a severity of 1
> The lower the number the more severe it is.
>
> Short Description
> Sequence cannot be deleted
>
> Long Description A Sequence is created automatically with the SQL
> command:
>
On Fri, 1 Mar 2002, Victor Krasinsky wrote:
> Is it a known bug if optimizer, that Postgres can't use indexes created on a int8
>(bigint) ?
> This problem exists in 7.1.3 and even in 7.2.
You need to explicitly cast the constant that you're comparing to
bigint (1::bigint or CAST(1 as bigint)).
1 - 100 of 386 matches
Mail list logo
