Re: [BUGS] pg_dump/all doesn't output database ACLs (v7.3.4)
On Mon, 08 Sep 2003, Tom Lane wrote: > Ben Grimm <[EMAIL PROTECTED]> writes: > > On Thu, 04 Sep 2003, Tom Lane wrote: > >> Ben Grimm <[EMAIL PROTECTED]> writes: > >>> I haven't tried the 7.4 beta, so it may be fixed there - but in > >>> 7.3.4, pg_dumpall doesn't output global database ACL's. > >> > >> This is fixed for 7.4. > > > Is there a patch to backport this to the 7.3 series? > > No, but you can use 7.4's pg_dumpall against your 7.3 database. Sure, I tried it right away when you mentioned that it was fixed for 7.4. So doing an upgrade won't give any problems relating to database acl's, but we'll still have issues with user owned schemas. So.. what about all the people that are starting to use schemas now that they're available? For example, we went from about 1500 logical users using a few dozen tables to 1500 real users using schemas. Now, all of the data that is owned by a given user - rather than being mixed with all of the other users data - is consolidated into inherited versions of tables from the public schema. It all works quite well, and I'm not sure we'd have been able to do it this way with any other dbms. Of course, now we have 86,000 rows in pg_class and pg_dump takes 3x longer to run than it used to. What I'm getting at is that we use a development server that is loaded from a copy of the production server, and after we designed and tested the migration, redesigned the application to fit the new model, and finally did our application/schema upgrade a couple of weeks back we went to copy the new production database back to the development server. I was really surprised to find the bugs I did - and worried to know that the nightly backups I take are not going to be as simple to restore as just running 'bzcat backup.bz2 | psql'. I can make it work so it's not tragic for me; but I wonder about all the other people who are using schemas and/or database level permissions in the 7.3 series. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] to_timestamp and to_date fails in postgresql 7.1.3
Hi, A client is using postgresql 7.1.3, and to_date() and to_timestamp() functions fail sometimes,However they never do in postgresql 7.3.2. Are these bugs? Thx _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] bug report: pg_dump does not use CASCADE in DROP
Added to TODO: * Have pg_dump -c clear the database using dependency information --- Preston Landers wrote: > > POSTGRESQL BUG REPORT TEMPLATE > > > > Your name : Preston Landers > Your email address: [EMAIL PROTECTED] > > > System Configuration > - > Architecture (example: Intel Pentium) : > Intel Pentium II 500mhz (dual CPU) > > Operating System (example: Linux 2.0.26 ELF): > Linux 2.4.2-2smp (Redhat 7.1) > > PostgreSQL version (example: PostgreSQL-7.3): > PostgreSQL-7.4beta2 snapshot (from 2003/8/26.) > > Compiler used (example: gcc 2.95.2): > GCC 2.96 > > > Please enter a FULL description of your problem: > > > I'm not sure if this is a bug report, feature request, or evidence of my > infirmity, but here it goes: > > pg_dump from 7.3+ does not use the CASCADE in the DROP statements (when > the -c clean option is used.) > > This is a problem when you are trying to restore the dump back onto > the same site and tables already exist, or perhaps this is just an error > in my understanding of how you perform Postgresql backup and restores. > > > > Please describe a way to repeat the problem. Please try to provide a > concise reproducible example, if at all possible: > -- > > Do a pg_dump -c. Restore it back to the same site. The tables will > not be dropped if they have FK constraints or any other dependencies, > resulting in an incorrect restore. > > > If you know how this problem might be fixed, list the solution below: > - > > Simply include the CASCADE option on all DROP TABLE, INDEX, VIEW, and > TRIGGER statements. If you feel this is too dangerous, at least > provide it as a command-line option to pg_dump, so people don't have > to hand-edit their dump files to be able to restore them. > > > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > -- 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
[BUGS] PG 7.4 beta 2: COPY IN, arrays, and double quotes bug.
I spoted a trouble with the HEAD taged PG version CVS updated
on the 4th of september.
During a COPY FROM stdin query involving a VARCHAR[] column I
experienced troubles with values containing an escaped double quote.
The query was expressed like this on the application side:
"COPY my_table "
"(..., attribs) "
"FROM stdin WITH DELIMITER '\\t'"
One of the attribs value is piped to the backend as {"3/4\""}, this is
how the array appears on the wire, and PG rejected it with the
following message, as submited to syslog:
postgres[90257]: [51-1] ERROR: malformed array literal: "{"3/4""}"
Regards,
Bertrand.
P.S.: despites that this PG vresion was CVS updated after the release
of beta 2, it still identifies itself as beta1:
=> select version();
version
PostgreSQL 7.4beta1 on i386-unknown-freebsd4.5, compiled by GCC 2.95.3
(1 row)
When PG is compiled from a CVS working directory tree, it would be
nice if the output of the version() function could include a latest
update timestamp and maybe a list of the sticky tags.
--
%!PS
297.6 420.9 translate 90 rotate 0 setgray gsave 0 1 1{pop 0 180 moveto 100
180 170 100 170 -10 curveto 180 -9 180 -9 190 -10 curveto 190 100 100 180
0 180 curveto fill 180 rotate}for grestore/Bookman-LightItalic findfont
240 scalefont setfont -151.536392 -63.7998886 moveto (bp)show showpage
---(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] pg_dump/all doesn't output database ACLs (v7.3.4)
On Thu, 04 Sep 2003, Tom Lane wrote: > Ben Grimm <[EMAIL PROTECTED]> writes: > > I haven't tried the 7.4 beta, so it may be fixed there - but in > > 7.3.4, pg_dumpall doesn't output global database ACL's. > > This is fixed for 7.4. Is there a patch to backport this to the 7.3 series? Without it there is no reliable way to backup a database with more complicated permissions. I'm sure I'd just muddle through with a sed script to insert the grants at the right place should the need arise. But likewise - with the other bug I reported - pg_dump is generating sql that can't be executed because the users don't have permissions. The resulting SQL just won't work as is... and without intervention users can't restore/upgrade databases that have these types of permissions. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] help with mac osx 10.2.6
Hi Theodore I download 7.3.4 and build it !!! All of PostgreSQL successfully made. Ready to install. i am in OS X.2.6 and % gnumake -v GNU Make version 3.79, by Richard Stallman and Roland McGrath. Built for powerpc-apple-darwin6.0 Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc. i dont patch gcc 3.3 ... In gcc 3.1 all works ... now you can do this for build with gcc 3.1 : (if you need) sudo /usr/sbin/gcc_select 3.1 I am goiing to install gcc3.3 to see the probleme !!! Payman Theodore Petrosky <[EMAIL PROTECTED]> wrote: > Please help with a mac osx installation... I had > installed 7.3.4 on osx 10.2.6 some months ago. it was > a painless installation. I responded to someone on the > apple help list about installing. this person was > having a problem with the make stage. I didn't think > to retry making on my system. > > I did. I can not make it now. I am getting an error > > [postgres:~/postgres/postgresql-7.3.4 copy.4] > postgres% make > make -C doc all > make[1]: Nothing to be done for `all'. > make -C src all > make -C port all > gcc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes > -Wmissing-declarations -I../../src/include -c -o > isinf.o isinf.c > In file included from /usr/include/math.h:24, > from isinf.c:5: > /usr/include/architecture/ppc/math.h:128: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:128: error: parse > error before "__cplusplus" > /usr/include/architecture/ppc/math.h:129: error: > syntax error before "inline" > /usr/include/architecture/ppc/math.h:130: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:130: error: parse > error before "else" > /usr/include/architecture/ppc/math.h:131: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:132: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:140: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:140: error: parse > error before "__cplusplus" > /usr/include/architecture/ppc/math.h:141: error: > syntax error before "inline" > /usr/include/architecture/ppc/math.h:142: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:142: error: parse > error before "else" > /usr/include/architecture/ppc/math.h:143: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:144: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:151: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:151: error: parse > error before "__cplusplus" > /usr/include/architecture/ppc/math.h:152: error: > syntax error before "inline" > /usr/include/architecture/ppc/math.h:153: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:153: error: parse > error before "else" > /usr/include/architecture/ppc/math.h:154: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:155: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:163: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:163: error: parse > error before "__cplusplus" > /usr/include/architecture/ppc/math.h:164: error: > syntax error before "inline" > /usr/include/architecture/ppc/math.h:165: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:165: error: parse > error before "else" > /usr/include/architecture/ppc/math.h:166: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:167: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:175: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:175: error: parse > error before "__cplusplus" > /usr/include/architecture/ppc/math.h:176: error: > syntax error before "inline" > /usr/include/architecture/ppc/math.h:177: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:177: error: parse > error before "else" > /usr/include/architecture/ppc/math.h:178: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:179: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:187: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:187: error: parse > error before "__cplusplus" > /usr/include/architecture/ppc/math.h:188: error: > syntax error before "inline" > /usr/include/architecture/ppc/math.h:189: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:189: error: parse > error before "else" > /usr/include/architecture/ppc/math.h:190: error: > syntax error at '#' token > /usr/include/architecture/ppc/math.h:191: error: > syntax error at '#' token > make[2]: *** [isinf.o] Error 1 > make[1]: *** [all] Error 2 > make: *** [all] Error 2 > > any ideas... i believe the problem lies with the > december 2002 update to the developers tools. > > Thanks, > > Ted > > __ > Do you Yahoo!? > Yahoo! SiteBuilder - F
Re: [BUGS] help with mac osx 10.2.6
Find it
gcc 3.3 dont support space character (0x20) before #ifdef
try this :
test.c
#include
int main()
{
return 0;
}
gcc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes
-Wmissing-declarations -c -o
test.o test.c
you have the same errors ...
but this works
gcc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes
-Wmissing-declarations -E -c -o
test.o test.c
also
gcc -g -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -c -o
test.o test.c
Payman
Payman <[EMAIL PROTECTED]> wrote:
> Hi Theodore
> I download 7.3.4 and build it !!!
>
> All of PostgreSQL successfully made. Ready to install.
>
> i am in OS X.2.6 and
> % gnumake -v
> GNU Make version 3.79, by Richard Stallman and Roland McGrath.
> Built for powerpc-apple-darwin6.0
> Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99
> Free Software Foundation, Inc.
> i dont patch gcc 3.3 ...
> In gcc 3.1 all works ...
> now you can do this for build with gcc 3.1 : (if you need)
>
> sudo /usr/sbin/gcc_select 3.1
>
> I am goiing to install gcc3.3 to see the probleme !!!
>
> Payman
>
>
>
>
> Theodore Petrosky <[EMAIL PROTECTED]> wrote:
>
> > Please help with a mac osx installation... I had
> > installed 7.3.4 on osx 10.2.6 some months ago. it was
> > a painless installation. I responded to someone on the
> > apple help list about installing. this person was
> > having a problem with the make stage. I didn't think
> > to retry making on my system.
> >
> > I did. I can not make it now. I am getting an error
> >
> > [postgres:~/postgres/postgresql-7.3.4 copy.4]
> > postgres% make
> > make -C doc all
> > make[1]: Nothing to be done for `all'.
> > make -C src all
> > make -C port all
> > gcc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes
> > -Wmissing-declarations -I../../src/include -c -o
> > isinf.o isinf.c
> > In file included from /usr/include/math.h:24,
> > from isinf.c:5:
> > /usr/include/architecture/ppc/math.h:128: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:128: error: parse
> > error before "__cplusplus"
> > /usr/include/architecture/ppc/math.h:129: error:
> > syntax error before "inline"
> > /usr/include/architecture/ppc/math.h:130: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:130: error: parse
> > error before "else"
> > /usr/include/architecture/ppc/math.h:131: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:132: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:140: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:140: error: parse
> > error before "__cplusplus"
> > /usr/include/architecture/ppc/math.h:141: error:
> > syntax error before "inline"
> > /usr/include/architecture/ppc/math.h:142: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:142: error: parse
> > error before "else"
> > /usr/include/architecture/ppc/math.h:143: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:144: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:151: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:151: error: parse
> > error before "__cplusplus"
> > /usr/include/architecture/ppc/math.h:152: error:
> > syntax error before "inline"
> > /usr/include/architecture/ppc/math.h:153: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:153: error: parse
> > error before "else"
> > /usr/include/architecture/ppc/math.h:154: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:155: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:163: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:163: error: parse
> > error before "__cplusplus"
> > /usr/include/architecture/ppc/math.h:164: error:
> > syntax error before "inline"
> > /usr/include/architecture/ppc/math.h:165: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:165: error: parse
> > error before "else"
> > /usr/include/architecture/ppc/math.h:166: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:167: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:175: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:175: error: parse
> > error before "__cplusplus"
> > /usr/include/architecture/ppc/math.h:176: error:
> > syntax error before "inline"
> > /usr/include/architecture/ppc/math.h:177: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:177: error: parse
> > error before "else"
> > /usr/include/architecture/ppc/math.h:178: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:179: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc/math.h:187: error:
> > syntax error at '#' token
> > /usr/include/architecture/ppc
Re: [BUGS] PG 7.4 beta 2: COPY IN, arrays, and double quotes bug.
Bertrand Petit <[EMAIL PROTECTED]> writes:
> One of the attribs value is piped to the backend as {"3/4\""}, this is
> how the array appears on the wire, and PG rejected it with the
> following message, as submited to syslog:
> postgres[90257]: [51-1] ERROR: malformed array literal: "{"3/4""}"
Seems like a client-side quoting bug to me. Backslashes have to be
doubled at the sending end, because COPY itself will do one level of
backslash processing.
If the client-side code is ours, then it's our problem, but you did not
say what you are using...
> P.S.: despites that this PG vresion was CVS updated after the release
> of beta 2, it still identifies itself as beta1:
Sounds like you didn't re-run configure after updating. I doubt that
affects the COPY issue above, but it surely might cause some other
problems. My invariable procedure for updating from CVS is a complete
rebuild:
make distclean
cvs update
configure
make
This costs a few machine cycles but I figure that's cheap compared to my
time puzzling out meaningless failures.
regards, tom lane
---(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
Re: [BUGS] [GENERAL] plPGSQL bug in function creation
On Monday 08 September 2003 09:32, Marek Lewczuk wrote:
> Hello,
> I think that there is a bug in plPGSQL - or maybe I don't know something
> about this language. Try to create this function
[snip]
> And when i execute: SELECT test(NULL, 'buuu'); -> it returns me NULL
> value, when it should return "buuu". Well I think that something is
> wrong here.
>
> If I will modify this function again to this:
>
> CREATE FUNCTION "public"."test" (varchar, varchar) RETURNS text AS'
[snip]
> Everything is working OK.. So the problem is in TEXT type definition.
>
> I'm using PG 7.3.1 on Win/Cyg
Can't reproduce here:
CREATE OR REPLACE FUNCTION functest1(varchar, varchar) RETURNS varchar AS '
BEGIN
IF $1 THEN
RETURN $1;
ELSE
RETURN $2;
END IF;
END;
'LANGUAGE 'plpgsql' VOLATILE CALLED ON NULL INPUT SECURITY INVOKER;
CREATE OR REPLACE FUNCTION functest2(text, text) RETURNS varchar AS '
BEGIN
IF $1 THEN
RETURN $1;
ELSE
RETURN $2;
END IF;
END;
'LANGUAGE 'plpgsql' VOLATILE CALLED ON NULL INPUT SECURITY INVOKER;
SELECT functest1('A','B'), functest1(null,'B'), functest2('A','B'),
functest2(null,'B');
CREATE FUNCTION
CREATE FUNCTION
functest1 | functest1 | functest2 | functest2
---+---+---+---
A | B | A | B
(1 row)
richardh=# select version();
version
-
PostgreSQL 7.3.2 on i686-pc-linux-gnu, compiled by GCC 2.96
Not sure whether this is because of the change 7.3.1->7.3.2 or cygwin vs
linux. Don't have a copy of 7.3.1 to check against, sorry. Perhaps check the
changes list to see if it mentions something like this.
--
Richard Huxton
Archonet Ltd
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] [SQL] [GENERAL] plPGSQL bug in function creation
I had the same success using 7.3.2 with Cygwin:
e=# SELECT functest1('A','B'), functest1(null,'B'), functest2('A','B'),
functest2(null,'B');
functest1 | functest1 | functest2 | functest2
---+---+---+---
A | B | A | B
(1 row)
e=# select version();
version
--
PostgreSQL 7.3.2 on i686-pc-cygwin, compiled by GCC gcc (GCC) 3.2 20020927
(prerelease)
(1 row)
George
- snip -
> Not sure whether this is because of the change 7.3.1->7.3.2 or cygwin vs
> linux. Don't have a copy of 7.3.1 to check against, sorry. Perhaps check
the
> changes list to see if it mentions something like this.
>
> --
> Richard Huxton
> Archonet Ltd
>
> ---(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
>
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] [GENERAL] plPGSQL bug in function creation
Marek Lewczuk wrote:
Hello,
I think that there is a bug in plPGSQL - or maybe I don't know something
about this language. Try to create this function
Ok., this is the function created in plPGSQL:
CREATE FUNCTION "public"."test" (text, text) RETURNS text AS'
BEGIN
IF $1 THEN
RETURN $1;
ELSE
RETURN $2;
END IF;
END;
'LANGUAGE 'plpgsql' VOLATILE CALLED ON NULL INPUT SECURITY INVOKER;
If you will execute SELECT test('tess', 'erer') -> then "tess" will be
returned. If you will execute: SELECT test(NULL, 'buuu'); -> then it
will return NULL, but it should return "buuu". I tried to figure out why
it is happening so i modifye this function to this:
CREATE FUNCTION "public"."test" (text, text) RETURNS text AS'
BEGIN
RETURN 'test';
END;
'LANGUAGE 'plpgsql' VOLATILE CALLED ON NULL INPUT SECURITY INVOKER;
And when i execute: SELECT test(NULL, 'buuu'); -> it returns me NULL
value, when it should return "buuu". Well I think that something is
wrong here.
If I will modify this function again to this:
CREATE FUNCTION "public"."test" (varchar, varchar) RETURNS text AS'
BEGIN
IF $1 THEN
RETURN $1;
ELSE
RETURN $2;
END IF;
END;
'LANGUAGE 'plpgsql' VOLATILE CALLED ON NULL INPUT SECURITY INVOKER;
Everything is working OK.. So the problem is in TEXT type definition.
I'm using PG 7.3.1 on Win/Cyg
---(end of broadcast)---
TIP 8: explain analyze is your friend
You can only test for NULL with 'IS NULL'.
NULL is NOT:
FALSE, 0, or F
---(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
