Re: [BUGS] ALTER SCHEMA problem
Bruce Momjian <[EMAIL PROTECTED]> writes: > Can someone comment on this? This is unfixable as long as nextval() and friends depend on string parameters to represent table references. There are suggestions in our archives about how we might move to a more Oracle-like syntax (ie, table.nextval), which would expose the table reference in a way that could track renamings. But no one seems to have gotten really excited about making it happen. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] small bug in op + between datetime and integer
Bruce Momjian <[EMAIL PROTECTED]> writes: > Anyone have an idea on this one? There's a date + integer operator, but no integer + date operator. Yawn... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] Reading from a read-only BLOB is allowed
Gonzalo Paniagua Javier <[EMAIL PROTECTED]> writes: > It seems that postgres allows writing to a read-only blob opened like: > fd = lo_open (cnc, oid, INV_READ); AFAICS from the code, INV_READ/WRITE attached to lo_open only determine the kind of lock taken on the LO (shared or exclusive). Not sure whether it's a bug to prohibit the other kind of access or not. Note that there's no "security" issue here, since anyone is allowed to write any LO anyway. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] small bug in op + between datetime and integer
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Anyone have an idea on this one? > > There's a date + integer operator, but no integer + date operator. > Yawn... Uh, "Yawn" means we don't need to fix it, or "oh, here's another one"? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] small bug in op + between datetime and integer
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> There's a date + integer operator, but no integer + date operator. >> Yawn... > Uh, "Yawn" means we don't need to fix it, or "oh, here's another one"? It means "I can't get excited about it." The docs don't claim that we have such an operator (do they?) and I see no clear advantage to adding one. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] small bug in op + between datetime and integer
Oh, OK. --- Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> There's a date + integer operator, but no integer + date operator. > >> Yawn... > > > Uh, "Yawn" means we don't need to fix it, or "oh, here's another one"? > > It means "I can't get excited about it." The docs don't claim that we > have such an operator (do they?) and I see no clear advantage to adding > one. > > regards, tom lane > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] ALTER SCHEMA problem
Can someone comment on this?
---
Andreas Hinz wrote:
> 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 but solved it and generated a patch
> then e-mail it to [EMAIL PROTECTED] instead. Please use the
> command "diff -c" to generate the patch.
>
> You may also enter a bug report at http://www.postgresql.org/ instead of
> e-mail-ing this form.
>
> =
> ===POSTGRESQL BUG REPORT TEMPLATE
> =
> ===
>
>
> Your name : Andreas Hinz
> Your email address: [EMAIL PROTECTED]
>
>
> System Configuration
> -
> Architecture (example: Intel Pentium) : Intel Pentium
>
> Operating System (example: Linux 2.0.26 ELF): Linux 2.4.21 ELF
>
> PostgreSQL version (example: PostgreSQL-7.3): PostgreSQL-7.4beta1
>
> Compiler used (example: gcc 2.95.2): gcc 3.2.3
>
>
> Please enter a FULL description of your problem:
>
>
> Hi,
> I am not absolutly sure this is a bug, but consider this:
>
> I am about to create a database with 5 schemas each containing about 70
> tables. Importing data via "psql -f .
>
> After import I rename the schema "public" to eg. "base1", create a
> new schema "public", import the next database etc.
>
> Now the problem is I yse the datatype "serial" which creates then
> constraint "default nextval('public.abc_sew'::test)".
>
> When renaming the schema from "public" to "base1" all indexes and
> seqenses are renames correct, but not the above "public." in the
> constraint.
>
>
> Please describe a way to repeat the problem. Please try to provide a
> concise reproducible example, if at all possible:
> --
>
> createdb test
> psql test
> CREATE TABLE ta1 (f1 serial, f2 integer);
> ALTER SCHEMA public RENAME TO base1;
> \d base1.*
>
>
> If you know how this problem might be fixed, list the solution below:
> -
>
>
> Only by manual "ALTER TABLE ta1 ALTER f1 SET DEFAULT etc.
>
> But doing this for 5 schemas each having 70 tables is somewhat stupud.
>
> Even via a seperate file with all the "ALTER" is no solution as this is
> an unfineshed project with frequent changes on the tables and thus
> possible changes in this file.
>
>
> A posibility to select a default schema with eg. "SET" on import would be
> a really nice feature:
>
> SET DEFAULT SCHEMA base1;
>
> CREATE TABLE
>
> COPY FROM stdin
>
> etc.
>
> --
> Med venlig hilsen / Best regards / Mit freundlichen Gr?ssen
>
> Andreas Hinz
>
> ---(end of broadcast)---
> TIP 6: Have you searched our list archives?
>
>http://archives.postgresql.org
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [BUGS] small bug in op + between datetime and integer
Anyone have an idea on this one? --- Pavel Stehule wrote: > Hello > > It is maybe not bug, but I didn't find any warning about this behavior. > > select current_date + 1; -- ok > select 1 + current_date; -- not > > ERROR: operator does not exist: integer + date > HINT: No operator matches the given name and argument type(s). You may > need to add explicit typecasts. > > I use CVS version of PostgreSQL from last week > > regards > > Pavel Stehule > > > ---(end of broadcast)--- > TIP 7: don't forget to increase your free space map settings > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] DBD::Pg 'lo_read' fails on >= 32768 byte large objects
Kevin Houle wrote: Tom Lane wrote: Kevin Houle <[EMAIL PROTECTED]> writes: Is it just me, or are both sides reading waiting for the other side to send data? Sure looks like it. Could it be an OpenSSL bug? One more data point. The DBD::Pg 'lo_extract' function works fine across SSL. There is no issue with large objects >= 32K using 'lo_extract'. So that casts doubt on it being an OpenSSL issue. Is there a different code path within libpq.so to move data from the server to the client via SSL for lo_extract than for lo_read that we can learn from? I'm looking at the code, but for the first time. s/lo_extract/lo_export/ Must work less. Kevin ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] DBD::Pg 'lo_read' fails on >= 32768 byte large objects
Tom Lane wrote: Kevin Houle <[EMAIL PROTECTED]> writes: Is it just me, or are both sides reading waiting for the other side to send data? Sure looks like it. Could it be an OpenSSL bug? One more data point. The DBD::Pg 'lo_extract' function works fine across SSL. There is no issue with large objects >= 32K using 'lo_extract'. So that casts doubt on it being an OpenSSL issue. Is there a different code path within libpq.so to move data from the server to the client via SSL for lo_extract than for lo_read that we can learn from? I'm looking at the code, but for the first time. Kevin ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] DBD::Pg 'lo_read' fails on >= 32768 byte large objects
Kevin Houle wrote: One more data point. The DBD::Pg 'lo_extract' function works fine across SSL. There is no issue with large objects >= 32K using 'lo_extract'. So that casts doubt on it being an OpenSSL issue. Is there a different code path within libpq.so to move data from the server to the client via SSL for lo_extract than for lo_read that we can learn from? I'm looking at the code, but for the first time. This looks suspicious. $ pwd; find . -type f | xargs grep inv_read /local/kjh/pgRPM/postgresql-7.3.4/src ./backend/libpq/be-fsstubs.c: status = inv_read(cookies[fd], buf, len); ./backend/libpq/be-fsstubs.c: while ((nbytes = inv_read(lobj, buf, BUFSIZE)) > 0) ./backend/storage/large_object/inv_api.c:inv_read(LargeObjectDesc *obj_desc, char *buf, int nbytes) ./include/storage/large_object.h:extern int inv_read(LargeObjectDesc *obj_desc, char *buf, int nbytes); inv_read(cookies[fd], buf, len) is in lo_read() inv_read(lobj, buf, BUFSIZE) is in lo_export() ./backend/libpq/be-fsstubs.c:#define BUFSIZE8192 The lo_export() function loops calling inv_read() until the entire object is read. The lo_read() function simply passes the number of bytes to be read to a single invocation of the inv_read() function. So if I use a length >= 32768 for lo_read(), it is happily passed to inv_read in an int datatype, which is 32k. Seems to me lo_read() should loop around inv_read() using BUFSIZE like lo_export() does. Kevin ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] error in docs
On Sun, 17 Aug 2003, andrea gelmini wrote: > test=# SELECT * FROM sal_emp WHERE pay_by_quarter[1:4] *= 1; > ERROR: Unable to identify an operator '*=' for types 'integer[]' and 'integer' > You will have to retype this query using an explicit cast I see from those docs: However, this quickly becomes tedious for large arrays, and is not helpful if the size of the array is unknown. Although it is not part of the primary PostgreSQL distribution, there is an extension available that defines new functions and operators for iterating over array values. Using this, the above query could be: SELECT * FROM sal_emp WHERE pay_by_quarter[1:4] *= 1; --- This is talking about an extension that's not part of the primary distribution as described in the paragraph before the example. I believe it's refering to contrib/array. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] error in docs
andrea gelmini wrote: test=# SELECT * FROM sal_emp WHERE pay_by_quarter[1:4] *= 1; ERROR: Unable to identify an operator '*=' for types 'integer[]' and 'integer' You will have to retype this query using an explicit cast There's nothing wrong with the docs (well, at least not with respect to your specific problem), you just need to read them again. Here's a quote from the link you supplied: "However, this quickly becomes tedious for large arrays, and is not helpful if the size of the array is unknown. Although it is not part of the primary PostgreSQL distribution, there is an extension available that defines new functions and operators for iterating over array values. Using this, the above query could be:" <...snip...> "To install this optional module, look in the contrib/array directory of the PostgreSQL source distribution." I have no idea how to install contrib/array using debian's package manager, but that's what you need to do. HTH, Joe ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] error in docs
Hi all,
I'm in trouble with examples in
http://www.postgresql.org/docs/7.3/interactive/arrays.html.
Step by step:
-cut here---
[EMAIL PROTECTED]:~$ createdb test
CREATE DATABASE
[EMAIL PROTECTED]:~$ psql test
Welcome to psql 7.3.3, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
test=# CREATE TABLE sal_emp (
test(# nametext,
test(# pay_by_quarter integer[],
test(# scheduletext[][]
test(# );
CREATE TABLE
test=# INSERT INTO sal_emp
test-# VALUES ('Bill',
test(# '{1, 1, 1, 1}',
test(# '{{"meeting", "lunch"}, {}}');
INSERT 44628 1
test=#
test=# INSERT INTO sal_emp
test-# VALUES ('Carol',
test(# '{2, 25000, 25000, 25000}',
test(# '{{"talk", "consult"}, {"meeting"}}');
INSERT 44629 1
test=# SELECT name FROM sal_emp WHERE pay_by_quarter[1] <>
pay_by_quarter[2];
name
---
Carol
(1 row)
test=# SELECT pay_by_quarter[3] FROM sal_emp;
pay_by_quarter
1
25000
(2 rows)
test=# SELECT schedule[1:2][1:1] FROM sal_emp WHERE name = 'Bill';
schedule
--
{{meeting},{""}}
(1 row)
test=# SELECT schedule[1:2][1] FROM sal_emp WHERE name = 'Bill';
schedule
--
{{meeting},{""}}
(1 row)
test=# UPDATE sal_emp SET pay_by_quarter = '{25000,25000,27000,27000}'
test-# WHERE name = 'Carol';
UPDATE 1
test=# UPDATE sal_emp SET pay_by_quarter[4] = 15000
test-# WHERE name = 'Bill';
UPDATE 1
test=# UPDATE sal_emp SET pay_by_quarter[1:2] = '{27000,27000}'
test-# WHERE name = 'Carol';
UPDATE 1
test=#
test=# CREATE TABLE tictactoe (
test(# squares integer[3][3]
test(# );
CREATE TABLE
test=#
test=# SELECT array_dims(schedule) FROM sal_emp WHERE name = 'Carol';
array_dims
[1:2][1:1]
(1 row)
test=# SELECT * FROM sal_emp WHERE pay_by_quarter[1] = 1 OR
test-# pay_by_quarter[2] = 1 OR
test-# pay_by_quarter[3] = 1 OR
test-# pay_by_quarter[4] = 1;
name | pay_by_quarter | schedule
--+---+--
Bill | {1,1,1,15000} | {{meeting},{""}}
(1 row)
test=# SELECT * FROM sal_emp WHERE pay_by_quarter[1:4] *= 1;
ERROR: Unable to identify an operator '*=' for types 'integer[]' and 'integer'
You will have to retype this query using an explicit cast
---cut here--
Well, Debian Sid, with these packages installed:
ii postgresql 7.3.3-1 Object-relational SQL database, descended from
POSTGRES
ii postgresql-client 7.3.3-1 Front-end programs for PostgreSQL
ii postgresql-dev 7.3.3-1 Header files for libpq (postgresql library)
ii postgresql-doc 7.3.3-1 Documentation for the PostgreSQL database
Thanks a lot for your work,
Andrea Gelmini
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[BUGS] Reading from a read-only BLOB is allowed
Hi!
It seems that postgres allows writing to a read-only blob opened like:
fd = lo_open (cnc, oid, INV_READ);
I've attached a simple test case and the Makefile to build it.
I'm using postgresql 7.3.3 (7.3.3-1 is the debian package version).
Is that the intended behaviour or is it a bug?
-Gonzalo
P.S.: please, CC me as I'm not suscribed to this list. Thanks.
--
Gonzalo Paniagua Javier <[EMAIL PROTECTED]>
http://www.gnome-db.org/~gonzalo/
#include
#include
#include
static char *conn_string =
"dbname=test user=gonzalo password=password hostaddr=127.0.0.1";
int
main ()
{
PGconn *cnc;
PGresult *res;
int oid, fd;
char *the_string = "The String";
char *other_str = "";
int written;
int result = 0;
cnc = PQconnectdb (conn_string);
if (PQstatus (cnc) != CONNECTION_OK) {
printf ("Error connecting: %s\n", PQerrorMessage (cnc));
return -1;
}
res = PQexec (cnc, "begin");
PQclear(res);
oid = lo_creat (cnc, INV_READ | INV_WRITE); /* Don't care if only one is set */
fd = lo_open (cnc, oid, INV_READ);
if (fd < 0) {
printf ("Error opening BLOB: %s\n", PQerrorMessage (cnc));
return -1;
}
written = lo_write (cnc, fd, the_string, strlen (the_string));
if (written >= 0) {
printf ("ERROR: I was able to write %d bytes.\n", written);
result = 1;
} else {
printf ("It worked! %s\n", PQerrorMessage (cnc));
}
lo_close (cnc, fd);
lo_unlink (cnc, oid);
res = PQexec (cnc, "end");
PQclear (res);
PQfinish (cnc);
return result;
}
CC=gcc
CFLAGS = -g -I/usr/include/postgresql
LDFLAGS = -lpq
inversion-bug: inversion-bug.o
inversion-bug.o: inversion-bug.c
clean:;
rm -f *.o inversion-bug *~
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] DBD::Pg 'lo_read' fails on >= 32768 byte large objects
Tom Lane wrote: Kevin Houle <[EMAIL PROTECTED]> writes: Is it just me, or are both sides reading waiting for the other side to send data? Sure looks like it. Could it be an OpenSSL bug? Well, redhat-9 ships with openssl-0.9.7a so I tried it with openssl-0.9.7b and lo_read still caused a read() loop after 32768 bytes. Then I used a Debian sid machine for testing using the same test case. It uses postgresql 7.3.3 openssl 0.9.7b The lo_read worked flawlessly on the Debian box. So I grabbed the postgresql 7.3.3 packages from the PGDG website and tried those on redhat-9. Still experienced the loop after 32768 bytes. I'm at a bit of a loss here. It would be nice if someone else could run the test script (see original message in this thread) on a redhat-9 box to eliminate my environment from the equation. Kevin ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Bug #926: if old postgresql.jar in CLASSPATH, ant fails
Is this patch valid for inclusion in jdbc?
---
[EMAIL PROTECTED] wrote:
> Palle Girgensohn ([EMAIL PROTECTED]) reports a bug with a severity of 3
> The lower the number the more severe it is.
>
> Short Description
> if old postgresql.jar in CLASSPATH, ant fails
>
> Long Description
> See http://www.freebsd.org/cgi/query-pr.cgi?pr=48878
>
> If there is an older postgresql.jar file in the ant classpath when building a new
> postgresql.jar, it will fail.
>
> Sample Code
> Adding includeAntRuntime="no" to the compile target in build.xml, as suggested by
> Tetsurou Okazaki <[EMAIL PROTECTED]>, fixes the problem
>
> --- src/interfaces/jdbc/build.xml~ Sun Oct 20 02:10:55 2002
> +++ src/interfaces/jdbc/build.xml Mon Mar 3 12:10:37 2003
> @@ -101,7 +101,7 @@
>
>
>
> -
> + debug="${debug}">
>
>
>
>
>
> No file was uploaded with this report
>
>
> ---(end of broadcast)---
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to [EMAIL PROTECTED] so that your
> message can get through to the mailing list cleanly
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
