PostgreSQL version 7.3.3, GCC 2.96, Redhat 7.2
When issuing the following type of command:
ALTER TABLE table RENAME COLUMN x TO y
The column name change is not cascading through to RULEs on a VIEW.
For example I had a column named "id_security" in TABLE "tbl_valrule" and I had
a RULE on a view th
Good shot, after new compilation I haven't any problems.
Thank You
Pavel Stehule
On Thu, 14 Aug 2003, Tom Lane wrote:
> Pavel Stehule <[EMAIL PROTECTED]> writes:
> > In this morning I actualized my PostgreSQL source from CVS.
> > initdb goes without any problems. But createdb puts
> > SIGSEGV
"Donald Fraser" <[EMAIL PROTECTED]> writes:
> Not sure whether you classify this as a bug or not?
It's a bug --- it's fixed for 7.4. 7.3 has some problems with the
timing of constant simplification in queries vs. predicate expressions.
I'm surprised you can get it to use the index at all, though
"systems" <[EMAIL PROTECTED]> writes:
> When I ran a query using postgres 7.3.2 it took over 2 hours to run.
> I upgraded to version 7.3.4 and the same query takes 5 minutes.
And you are filing this as a bug because ... ?
regards, tom lane
---(end
POSTGRESQL BUG REPORT TEMPLATE
Your name : Diego Linke
Your email address : [EMAIL PROTECTED]
Syst
Christian van der Leeden <[EMAIL PROTECTED]> writes:
> the reason for this misbehaviour was an invalid timestamp value.
> I've tried to dump/restore the db and the restore choked on a
> "incorrect timestamp" namely:
> 4714-11--2147483624 -2147483648:-2147483648:-2147483648 BC
Hmm ... I'm sus
Christian van der Leeden <[EMAIL PROTECTED]> writes:
> without any index the range query returns the correct result namely
> 272394, when i create an index on creation_date,
> I get 10371 as a result.
This is a tad hard to believe :-(.
Could we see the full schema for the table? ("pg_dump -s -t
Postgresql 7.3.4 on Linux.
Problem is that when you create a table with serial type, it creates
sequence with coresponding name. Then you can grant some rights to
it (table and sequence), and after that change table name. From now on
you will not be able to restore such database, because name of s
Hi there,
Recently I stumbled over a very strange problem: I had two very similar
setups (RHL9 with latest updates, pgsql-7.3.2, parameters in "show all"
the same, databases with encoding=UNICODE, loaded from the same database
dump) where the sorting on one was erroneous with regards to accented
c
Newer versions of TCL implement ByteArray objects which are
the best fit for Postgresql Large Object functions. The change
is simple. Here's a diff on the 7.4 source file and a fixed version:
diff pgtclCmds.c pgtclCmds.c.fixed
1218c1218
< bufObj = Tcl_NewStringObj(buf, nbytes);
---
> b
hi all
it would be good to have RETURNING clause in INSERT,UPDATE,DELETE queries.
similar to Oracle's one but more clever.
Oracle's "RETURNING" is just a disguised independant SELECT wich is not
wanted.
i found "RETURNING" usable if it returns just inserted or just deleted record.
e.g. i have som
Philipp Reisner <[EMAIL PROTECTED]> writes:
> strncpy(fstr, (cp + 1), 7);
> + fstr[7]=0;
> strcpy((fstr + strlen(fstr)), "00");
After some looking around, it turns out there was another similar error,
plus several related pl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, August 12, 2003 08:47:08 AM -0700 Stephan Szabo
<[EMAIL PROTECTED]
.bigpanda.com> wrote:
On Tue, 12 Aug 2003, Kevin Houle wrote:
>> There is an email attachment (md5: 5cc780da645df9516235d43d1cf1e8b5)
>> which contains a file with two
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Your name : Kevin Houle
Your email address : [EMAIL PROTECTED]
System Configuration
- --
Architecture : i686
Operating System : RH9, 2.4.20-19
PostgreSQL version : PostgreSQL-7.3.4 (RPMS from PGDG)
Please ent
I just noticed something about how this is behaving. When I run the script
on my machines, it's putting the index data tb_c_ingredient into
tb_c_step_fti. If I exit psql, go back in and manually insert, it goes to
the correct table tb_c_ingredient_fti.
I wrote a much simpler script (see attachme
Hello,
In Jim Melton and Alan Simon's "SQL:1999 - Understanding Relational
Language Components" (ISBN 1-55860-456-1), they write that the following
is to be interpreted as a TIMESTAMP WITH TIME ZONE value:
TIMESTAMP '2003-07-29 13:19:30.5+02:00'
PostgreSQL interprets the above as a TIMESTAMP WIT
Diego Linke - GAMK <[EMAIL PROTECTED]> writes:
> The problem is that postgresql when calls a function in external C,
> calls with user of the postgres.
The ability to create C functions is reserved to superusers, for exactly
this reason. If you have the rights to make the backend execute
arbitrar
Troels Arvin <[EMAIL PROTECTED]> writes:
> In Jim Melton and Alan Simon's "SQL:1999 - Understanding Relational
> Language Components" (ISBN 1-55860-456-1), they write that the following
> is to be interpreted as a TIMESTAMP WITH TIME ZONE value:
> TIMESTAMP '2003-07-29 13:19:30.5+02:00'
> Postgre
Nils Philippsen writes:
> On Mon, 2003-08-11 at 10:49, Peter Eisentraut wrote:
> > Nils Philippsen writes:
> >
> > > Is this expected behaviour
> >
> > Yes.
>
> Hmm. I ask myself whether this is desired behaviour, too.
No, but it will take a lot of work to fix this, such as implementing our
own l
PostgreSQL 7.3.3, GCC 2.96 on Redhat
7.2
Not sure whether you classify this as a bug or
not?
Anyway here goes:
I have a partial index such as:
CREATE UNIQUE INDEX tbl_test_key ON
tbl_test USING btree (s_mnem) WHERE ((n_status
& (~9)) <> 0);
I have a select statement such as:
SELECT s
Just a followup:
the reason for this misbehaviour was an invalid timestamp value.
I've tried to dump/restore the db and the restore choked on a
"incorrect timestamp" namely:
4714-11--2147483624 -2147483648:-2147483648:-2147483648 BC
(out of the dump file)
After I've elimnated the lines con
On Thu, 14 Aug 2003, Diego Linke - GAMK wrote:
> Your name : Diego Linke
> Your email address : [EMAIL PROTECTED]
>
> System Configuration
> -
> Architecture (example: Intel Pentium) : Intel
>
> Operating System (example: Linux 2.0.26 ELF) : NetB
Hi,
I've put the database dump here:
http://www.vanderleeden.de/test/databasedumps.tar
(about 16 MB)
It contains the ascii dump of pg_dump and the
pg_dump --format c of the database.
I've only got the dumps left of the original problem,
since during my tries to remedy the problem
(upgrade
On Mon, 2003-08-11 at 10:49, Peter Eisentraut wrote:
> Nils Philippsen writes:
>
> > Is this expected behaviour
>
> Yes.
Hmm. I ask myself whether this is desired behaviour, too.
Given that this isn't obviously documented (at least I didn't find it),
I'd expect sort order to be dependent on ser
On Tue, 12 Aug 2003, Kevin Houle wrote:
> System Configuration
> - --
> Architecture : i686
>
> Operating System : RH9, 2.4.20-19
>
> PostgreSQL version : PostgreSQL-7.3.4 (RPMS from PGDG)
>
> Please enter a FULL description of your problem:
> -
On Thu, 7 Aug 2003, Silvio Scarpati wrote:
> this seems a serious bug:
>
> testdb=>
> testdb=> create table t1(a int, b text);
> CREATE TABLE
> testdb=> create table t2(a int, b text);
> CREATE TABLE
> testdb=> insert into t1 values(1,'pippo');
> INSERT 7591667 1
> testdb=> insert into t1 values(2
Non superusers can set log_statement to true but can't set it
back to false even if log_statement was false at the begining of a
connection.
I think lambda users should be able to revert log_statement to
false when false is the default setting.
--
%!PS
297.6 420.9 translate 90 r
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Okay, I see it with en_US.UTF-8, but not with C locale, nor with
> en_US or en_US.iso885915. It looks like the comparison rules are
> different between the locales (and I'm not sure if SQL_ASCII encoding
> and a UTF8 locale makes sense in practice).
I'd
On Tue, 12 Aug 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > Okay, I see it with en_US.UTF-8, but not with C locale, nor with
> > en_US or en_US.iso885915. It looks like the comparison rules are
> > different between the locales (and I'm not sure if SQL_ASCII encoding
> >
On Wed, 6 Aug 2003 at 18:02, Tom Lane wrote:
> Mahlon Stacy <[EMAIL PROTECTED]> writes:
> > Newer versions of TCL implement ByteArray objects which are
> > the best fit for Postgresql Large Object functions.
>
> How newer is "newer"? That is, what compatibility problems might we
> create if we ma
Hi Stephan,
>
> Only a bad database superuser should be able to do anything of the sort
> because normal users shouldn't be allowed to use CREATE FUNCTION with C
> language functions (it's untrusted), are you seeing something different?
>
I am sorry!
I really did not perceive that only one adm
Hello
In this morning I actualized my PostgreSQL source from CVS.
initdb goes without any problems. But createdb puts
SIGSEGV, createuser, psql too.
[EMAIL PROTECTED] root]$ ltrace psql -l
__libc_start_main(0x08050df0, 2, 0xb3a4, 0x08049e98, 0x0805a810
__register_frame_info_bases(0x0806b7
Stephan Szabo <[EMAIL PROTECTED]> writes:
> I don't know enough about the issues involved. Can we reasonably tell
> that a particular locale and encoding don't make sense together (apart
> from things like looking for UTF-8 in the name for example)?
There was some discussion about this a week or
I'm not a subscriber to the list. Please copy any responses directly to me.
Thanks.
It's such a minor, but annoying bug, and is easily fixed:
The stock startup script included in the RPM (I currently use the 7.3.3 RPM
for RH7.3), /etc/rc.d/init.d/postgresql, sets the service name (the $NAME
varia
POSTGRESQL BUG REPORT TEMPLATE
Your name : Christopher Marshall
Your email address : [EMAIL PROTECTED]
Sys
Bertrand Petit <[EMAIL PROTECTED]> writes:
> Non superusers can set log_statement to true but can't set it
> back to false even if log_statement was false at the begining of a
> connection.
Yeah. I think that the restrictions for USERLIMIT variables ought to
compare against the reset_val, n
When I ran a query using postgres 7.3.2 it took over 2 hours to run.
I upgraded to version 7.3.4 and the same query takes 5 minutes.
This was with absolutely no changes to indexes or any of the queries.
I used the default install, and didn't tweak any settings in postgresql.conf
Kernel version: S
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, August 12, 2003 08:18:53 AM -0700 Stephan Szabo
<[EMAIL PROTECTED]
.bigpanda.com> wrote:
On Tue, 12 Aug 2003, Kevin Houle wrote:
System Configuration
- --
Architecture : i686
Operating System : RH9, 2.4.20-19
On Tue, 12 Aug 2003, Kevin Houle wrote:
> >> There is an email attachment (md5: 5cc780da645df9516235d43d1cf1e8b5)
> >> which contains a file with two SQL INSERT commands to insert two rows
> >> into a test table. The table should look like this:
> >>
> >> CREATE TABLE tbl_test (
> >> testcol
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Nils Philippsen writes:
>> Hmm. I ask myself whether this is desired behaviour, too.
> No, but it will take a lot of work to fix this, such as implementing our
> own locale library.
We should, however, look into using C99-spec routines where
availab
Oh, and the error message listed in SQL92 for out of range timezone is:
data exception-invalid time zone displacement value
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's
If PostgreSQL failed to compile on your computer or you found a bug that
is likely to be specific to one platform then please fill out this form
and e-mail it to [EMAIL PROTECTED]
To report any other bug, fill out the form below and e-mail it to
[EMAIL PROTECTED]
If you not only found the problem
Hello,
There appears to be a bug in the code used by DBD::Pg's 'lo_read'
function. I presume the code with the bug is a part of libpq, and
thus the postgresql-libs RPM binary distribution.
The nature of the bug is that an 'lo_read' operation performed
with DBD::Pg caused a segfault with postgresql
Hello list!
I'm using postgresql 7.3.2r1-6.woody
from http://people.debian.org/~elphick/debian
in some production enviroment.
I had in the past with the stable release of postgres in debian woody a
problem about
"enlarging tables". In particular session tables with a lot of traffic
became fro
Just two minor issues with timestamps:
Error message is currently:
create table test (ts timestamp);
-- insert an illegal date:
insert into test values ('20021131');
invalid input syntax for timestamp: "20021131"
SQL92 and 99 say it should be:
data exception-datetime field overflow
No big dea
Ruslan A Dautkhanov <[EMAIL PROTECTED]> writes:
> Is this mean, that PostgresSQL will not have recode() futher ?
That's right. Use the more general character-set-conversion
functionality, instead.
regards, tom lane
---(end of broadcast)---
Matteo <[EMAIL PROTECTED]> writes:
> INFO: --Relation public.active_sessions_split--
> INFO: Index active_sessions_split_pkey: Pages 91838; Tuples 5381: Deleted 31.
> CPU 4.26s/0.47u sec elapsed 135.47 sec.
> INFO: Index k_asp_changed: Pages 46192; Tuples 5381: Deleted 31.
> CPU
Hi Stephan,
Thanks a lot for the answer.
On Thu, 7 Aug 2003 15:10:00 -0700 (PDT), you wrote:
>> instead of the required one.
>
>That is the required resultset. Union is required to do return only
>one copy of a row when there are duplicates of a row. Union all returns
>a number of copies equal
On Thu, 14 Aug 2003, scott.marlowe wrote:
> Just two minor issues with timestamps:
>
> Error message is currently:
>
> create table test (ts timestamp);
> -- insert an illegal date:
> insert into test values ('20021131');
> invalid input syntax for timestamp: "20021131"
>
> SQL92 and 99 say it sh
> Wrong ! The query should return 4 rows. In other words i don't know
> why postgres performs the following query:
I think the syntax you're looking for is UNION ALL.
select a,b from t1 union all (select distinct a,b from t2);
signature.asc
Description: This is a digitally signed message part
"Donald Fraser" <[EMAIL PROTECTED]> writes:
> When issuing the following type of command:
> ALTER TABLE table RENAME COLUMN x TO y
> The column name change is not cascading through to RULEs on a VIEW.
More specifically, INSERTs and UPDATEs contained in rules don't have
their target column names ad
51 matches
Mail list logo
