[HACKERS] pg_regress gripes
A couple glitches to work out in pg_regress: 1. 'make installcheck' fails if PGPORT isn't set in environment. Should omit '-p $PGPORT' options from program invocations unless PGPORT is set. Actually, I think you should omit -p period; the programs are perfectly capable of reading PGPORT from the environment for themselves. 2. I get this behavior: test hash_index ... ok test misc ... FAILED test select_views ... ok test alter_table ... ok test portals_p2 ... ok test rules... ok test foreign_key ... ok test limit... ok test plpgsql ... ok test temp ... ok = 0 of 75 tests passed, 0 failed test(s) ignored. = (The misc failure is from a bug in some other stuff I'm working on; I show it just to illustrate that pg_regress's helpful totals are completely incorrect.) I presume the output is more useful for you, which probably means that echo behaves differently on your platform. Possibly should be looking for '\.\.\. *ok' and so on? regards, tom lane
Re: [HACKERS] Strange error message
Adriaan Joubert [EMAIL PROTECTED] writes: ERROR: UNLockBuffer: buffer 0 is not locked Right, I'vebuilt a new database and everything seemed fine for a while and now I've got this message back. It is due to the index on one of our tables getting messed up - at least, if we drop and recreate the index everything is fine. What should I do to track down what is happening? Compile with asserts, or run with specific logging? Compile with asserts and -g, and get a backtrace from the ensuing coredump. (LockBuffer *will* Assert when passed a zero. If we are really lucky, we might see an earlier Assert failure that will give more clue about where the zero comes from --- but if not, the backtrace from the bogus LockBuffer call might still be useful.) regards, tom lane
[HACKERS] www.postgresql.org
What happen with www.postgresql.org? My browser is always redirected to http://www.cz.postgresql.org/. But I haven't some terrible mirror (with last change "July 1999"), I want nice and native PG's web! :-) Karel PS. Exist some check what happen at PostgreSQL mirrors? The www.cz.postgresql.org is *discredit*... (sorry Czech friends).
[HACKERS] Note about include files
The file "postgres.h" (or "c.h" or "config.h", whatever is used) needs to be the very *first* file included by each source file. Next time you touch a source file, please check that this is the case. The obvious failure mode is that if config.h redefines const, volatile, or inline then it will cause confusion when some system headers are included before and some after that definition. The slightly more esoteric problem I encountered is that when you compile with CC='gcc -std=c99 -pedantic' on a glibc platform (i.e., "Linux") then you need to define _SVID_SOURCE and _BSD_SOURCE before including any system header in order to get the full feature set from the headers. (Unfortunately, the flex output does not observe this rule either, so we can't be 100% pedantic warning safe without doing surgery on those files.) On a related note, does anyone know why the on_proc_exit and on_shmem_exit hooks use a second argument of type `caddr_t' rather than, say, void*, char*, Datum, ...? This artifact is the cause of about two thirds of the compile errors in the pedantic setting. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Note about include files
* Peter Eisentraut [EMAIL PROTECTED] [001002 02:51] wrote: The file "postgres.h" (or "c.h" or "config.h", whatever is used) needs to be the very *first* file included by each source file. Next time you touch a source file, please check that this is the case. The obvious failure mode is that if config.h redefines const, volatile, or inline then it will cause confusion when some system headers are included before and some after that definition. The slightly more esoteric problem I encountered is that when you compile with CC='gcc -std=c99 -pedantic' on a glibc platform (i.e., "Linux") then you need to define _SVID_SOURCE and _BSD_SOURCE before including any system header in order to get the full feature set from the headers. (Unfortunately, the flex output does not observe this rule either, so we can't be 100% pedantic warning safe without doing surgery on those files.) gcc supports the '-include' directive which may be what you want. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
[HACKERS] libpq PGHOST
The current behaviour of libpq is to use Unix sockets whenever the host parameter (PGHOST or setdbLogin argument) is NULL/unset. Could we extend that to also use Unix sockets if the parameter is set but empty? That could avoid a bunch of shell contortions; e.g., you can't portably un-export variables, in some shells you don't even have "unset". Or would this be too incompatible? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] backup and restore
Hi, I would like to know if postgres comes with some kind of backup application? I mean something that would do database backup and restore, something like informix's ontape and logical logs. Thanks -- "And I'm happy, because you make me feel good, about me." - Melvin Udall - Martín Marqués email: [EMAIL PROTECTED] Santa Fe - Argentinahttp://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -
Re: [HACKERS] backup and restore
"Martin A. Marques" wrote: Hi, I would like to know if postgres comes with some kind of backup application? I mean something that would do database backup and restore, something like informix's ontape and logical logs. Take a look at pg_dump and pg_dumpall - Hannu
[HACKERS] failed assertion error on PG-7.0.2
Fresh from /var/log/postgres.log: postgres localhost www-data auction SELECT: ../iconv/skeleton.c:297: gconv: Asse rtion `outbufstart == ((void *)0)' failed. Server process (pid 27393) exited with status 6 at Mon Oct 2 09:01:43 2000 Starting a new postmaster seems to cure the problem. -- Louis-David Mitterrand - [EMAIL PROTECTED] - http://www.apartia.org Bill Gates to his broker: "You idiot, I said $150 million on **SNAPPLE**!!!"
Re: [HACKERS] Note about include files
Peter Eisentraut [EMAIL PROTECTED] writes: On a related note, does anyone know why the on_proc_exit and on_shmem_exit hooks use a second argument of type `caddr_t' rather than, say, void*, char*, Datum, ...? This artifact is the cause of about two thirds of the compile errors in the pedantic setting. I was annoyed by that just the other day on an Alpha box (it provokes lots of "integer cast to pointer of different size" warnings there). I'm sure the use of caddr_t is strictly historical. If you feel like doing something about it, changing the arguments of these routines to be Datum and then adding the necessary to-and-from-Datum macros seems like the obvious solution path. regards, tom lane
Re: [HACKERS] libpq PGHOST
Peter Eisentraut [EMAIL PROTECTED] writes: The current behaviour of libpq is to use Unix sockets whenever the host parameter (PGHOST or setdbLogin argument) is NULL/unset. Could we extend that to also use Unix sockets if the parameter is set but empty? Seems reasonable, since the current behavior in that case is useless: $ PGHOST='' psql psql: connectDBStart() -- unknown hostname: $ Backwards compatibility with that doesn't seem necessary ... regards, tom lane
Re: [HACKERS] failed assertion error on PG-7.0.2
Louis-David Mitterrand [EMAIL PROTECTED] writes: Fresh from /var/log/postgres.log: postgres localhost www-data auction SELECT: ../iconv/skeleton.c:297: gconv: Assertion `outbufstart == ((void *)0)' failed. ?? Anyone recognize that? A few seconds with glimpse shows that there is no file named skeleton.c, indeed no directory named iconv, in the current sources; much less any routine named gconv; nor any variable named outbufstart. So I'm pretty confused... regards, tom lane
Re: [HACKERS] failed assertion error on PG-7.0.2
Tom Lane [EMAIL PROTECTED] writes: Louis-David Mitterrand [EMAIL PROTECTED] writes: Fresh from /var/log/postgres.log: postgres localhost www-data auction SELECT: ../iconv/skeleton.c:297: gconv: Assertion `outbufstart == ((void *)0)' failed. ?? Anyone recognize that? A few seconds with glimpse shows that there is no file named skeleton.c, indeed no directory named iconv, in the current sources; much less any routine named gconv; nor any variable named outbufstart. So I'm pretty confused... glibc, related to i18n. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [HACKERS] www.postgresql.org
Removed from redirect. Vince. On Mon, 2 Oct 2000, Karel Zak wrote: What happen with www.postgresql.org? My browser is always redirected to http://www.cz.postgresql.org/. But I haven't some terrible mirror (with last change "July 1999"), I want nice and native PG's web! :-) Karel PS. Exist some check what happen at PostgreSQL mirrors? The www.cz.postgresql.org is *discredit*... (sorry Czech friends). -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com ==
Re: [HACKERS] Solution for RI permission problem
On Sun, 1 Oct 2000, Peter Eisentraut wrote: Stephan Szabo writes: With that, I do have a general question though. Are referential actions supposed to be limited by the permissions of the user executing the query? So, if you for example have write access on the pk table, but not to the fk table, and there is a on cascade delete relationship, should that user not be able to delete from the pk table? Then you could delete records that are not in relation to the foreign keys in your table. So I suppose not. Of course there does seem to be a very limited range of usefulness of such a setup, but we shouldn't extrapolate something potentially more useful from that. Actually, I'm mostly confused about what the spec wants done. The section on the referential actions says things like "the rows are marked for deletion" without and I can't find something there that says whether or not you are actually supposed to pay attention to the associated privs.
Re: [HACKERS] ecpg enhance patch
I have committed this patch. It offers a speed up to ecpg.
Michael Meskes [EMAIL PROTECTED] wrote:
On Sat, Jun 03, 2000 at 11:22:19AM +0900, SAKAIDA Masaaki wrote:
The following patch could solve the next error cases in 6.5.3-ecpglib.
case 1.
strcpy(str, "T''EST'TEST");
exec sql insert into ecpg_test values ( 11, :str, 'kobe' ) ;
error(-201)(Too many arguments line 1025.
case 2.
str( str, "T'''?'ESTTEST");
exec sql insert into ecpg_test values ( 11, :str, 'kobe' ) ;
error(-202)(Too few arguments line 1024.)
However, these problems seems to be solved in 7.0-ecpglib.
So that means the patch is not needed anymore?
In the meaning of bug-fix, the patch is not needed. Because you
have already modified "next_insert()" in 7.0-ecpglib. However
in the meaning of speed-up, the patch will be needed.
--
Regards,
SAKAIDA Masaaki -- Osaka, Japan
*** postgresql-7.0.1/src/interfaces/ecpg/lib/execute.c.orig Tue Jun
6 15:02:34 2000
--- postgresql-7.0.1/src/interfaces/ecpg/lib/execute.cTue Jun 6 15:02:05
2000
***
*** 278,283
--- 278,284
char *tobeinserted = NULL;
char *p;
charbuff[20];
+ int hostvarl = 0;
/*
* Some special treatment is needed for records since we want
***
*** 559,565
return false;
strcpy(newcopy, copiedquery);
! if ((p = next_insert(newcopy)) == NULL)
{
/*
--- 560,566
return false;
strcpy(newcopy, copiedquery);
! if ((p = next_insert(newcopy + hostvarl)) == NULL)
{
/*
***
*** 572,577
--- 573,579
else
{
strcpy(p, tobeinserted);
+ hostvarl = strlen(newcopy);
/*
* The strange thing in the second argument is the rest of the
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] www.postgresql.org
The only fix is to do http://www.cz.postgresql.org/index.html This prevents mirror use. The old mirror should be fixed or removed. What happen with www.postgresql.org? My browser is always redirected to http://www.cz.postgresql.org/. But I haven't some terrible mirror (with last change "July 1999"), I want nice and native PG's web! :-) Karel PS. Exist some check what happen at PostgreSQL mirrors? The www.cz.postgresql.org is *discredit*... (sorry Czech friends). -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] www.postgresql.org
On Mon, 2 Oct 2000, Bruce Momjian wrote: The only fix is to do http://www.cz.postgresql.org/index.html It's returns still same a *bad* result. This prevents mirror use. The old mirror should be fixed or removed. ^^ Sure. I repost this mail to www.cz.postgresql.org admin at mendelu.cz... Karel PS. Thanks for redirect fix, www.postgresql.org is more nice :-) What happen with www.postgresql.org? My browser is always redirected to http://www.cz.postgresql.org/. But I haven't some terrible mirror (with last change "July 1999"), I want nice and native PG's web! :-) Karel PS. Exist some check what happen at PostgreSQL mirrors? The www.cz.postgresql.org is *discredit*... (sorry Czech friends).
[HACKERS] Reimplementing UNION/INTERSECT/EXCEPT
I've been looking at UNION/INTERSECT/EXCEPT with an eye to making them work in views and subselect-in-FROM (same thing really ;-)). I had first thought that some marginal hacking on the parsetree representation might be enough, but after study I am realizing just how broken this code really is. It turns out that it's not even very close to implementing the SQL spec. SQL92 7.10, general rule 1b says that if a row R has m duplicates in T1 and n duplicates in T2 (m = 0, n = 0) then: Set operation: contains this many duplicates of R: T1 UNION T2 1 if m 0 or n 0, else 0 T1 INTERSECT T2 1 if m 0 and n 0, else 0 T1 EXCEPT T21 if m 0 and n = 0, else 0 T1 UNION ALL T2 m + n T1 INTERSECT ALL T2 min(m, n) T1 EXCEPT ALL T2max(m - n, 0) We are OK for UNION (which we do as append, sort, unique) and for UNION ALL (which we do as append). We are not OK for INTERSECT and EXCEPT, which the code presently tries to do as SELECT T1 INTERSECT SELECT T2 = SELECT T1 WHERE T1 IN (SELECT T2) SELECT T1 EXCEPT SELECT T2 = SELECT T1 WHERE T1 NOT IN (SELECT T2) This will give the wrong number of duplicates when m 1. It could be made to give the right answer by adding a DISTINCT to the select, but there's still no expansion path for implementing INTERSECT ALL and EXCEPT ALL. There are a bunch of internal problems too (which is why views didn't support UNION et al to begin with), mostly due to bad choices of data structures. I have come to the conclusion that there's no point in half measures: throwing out this code and rewriting from scratch will take less time than trying to patch it. Here's what I have in mind: Parse-tree data structure (output of gram.y): remove unionClause/intersectClause from SelectStmt. Add a SetOperation node type that indicates the operation type (UNION/INTERSECT/EXCEPT plus an "all" boolean) and links to two component SelectStmts or SetOperations. There will be no loops in this data structure, unlike the present situation. The top-level info (optional ORDER BY) added by the SelectStmt production will be attached to the leftmost SelectStmt leaf in the tree. Query-tree structure (output of parse_analyze): process the leaf SelectStmts into Queries individually, after removing the OrderBy etc info from the leftmost leaf. Create a top-level Query that contains the leaf Queries as subselects-in-FROM. In place of unionClause/intersectClause, Query nodes will have a Node *setOperations field. In the top-level Query this will contain the SetOperation tree emitted by gram.y, but with the leaf SelectStmt nodes replaced by RangeTblRef references to the range table entries occupied by the leaf Queries. (Thus, still no loops or multiple links.) The top-level Query has a dummy targetlist that exists mainly to show the union'd datatype of each output column, and it carries any sortClause, limitClause, etc needed for the output of the entire operation. Note that we do not need to transform the datatypes of the leaf queries' targetlists, which eliminates a large class of bugs that exist presently with cross-datatype UNIONs. Rewriter: need pay no attention at all to setOperation tree. Plan-tree structure (output of planner): UNION/UNION ALL are handled same as now, except that what we are appending together is not directly the top-level plan of each leaf query, but a SubqueryScan plan scanning the output of each leaf query. This gives us one extra level of projection (targetlist evaluation) in which to put conversions to the common union datatype --- without breaking the semantics of GROUP BY, DISTINCT, and so forth in the leaf queries. INTERSECT and EXCEPT will be handled by building SubqueryScan plans that emit the common-datatype columns plus a resjunk boolean column that shows whether the tuple is coming from the left or right input. The outputs of these plans are then appended together, sorted, and fed to a new plan node type that implements INTERSECT(ALL) and EXCEPT(ALL). It will be a simple generalization of the Unique plan type: scan a set of successive tuples that agree in all the non-resjunk columns, counting the number of tuples that came from left and right sides. This gives us 'm' and 'n' for each set, from which the spec-defined behavior can be implemented immediately. Executor: just need new plan-node-type implementation, which is easily derived from nodeUnique. I am not planning to try to implement SQL's "CORRESPONDING" option for 7.1. Whenever we do get to it, it should be a fairly straightforward extension: add the corresponding-column lists to SetOperation nodes, and then in the plan tree, make the SubqueryScan nodes emit just these columns and not the entire targetlists of the leaf Queries. (This is another reason why we need the extra level of targetlist...) Comments? regards, tom lane
Re: [HACKERS] www.postgresql.org
On Mon, 2 Oct 2000, Karel Zak wrote: On Mon, 2 Oct 2000, Bruce Momjian wrote: The only fix is to do http://www.cz.postgresql.org/index.html It's returns still same a *bad* result. This will bypass the redirect: http://www.postgresql.org/index.html Vince. This prevents mirror use. The old mirror should be fixed or removed. ^^ Sure. I repost this mail to www.cz.postgresql.org admin at mendelu.cz... Karel PS. Thanks for redirect fix, www.postgresql.org is more nice :-) What happen with www.postgresql.org? My browser is always redirected to http://www.cz.postgresql.org/. But I haven't some terrible mirror (with last change "July 1999"), I want nice and native PG's web! :-) Karel PS. Exist some check what happen at PostgreSQL mirrors? The www.cz.postgresql.org is *discredit*... (sorry Czech friends). -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com ==
Re: [HACKERS] www.postgresql.org
On Mon, 2 Oct 2000, Bruce Momjian wrote: The only fix is to do http://www.cz.postgresql.org/index.html It's returns still same a *bad* result. No, sorry, use: http://www.postgresql.org/index.html The index.html prevents the redirect. This prevents mirror use. The old mirror should be fixed or removed. ^^ Sure. I repost this mail to www.cz.postgresql.org admin at mendelu.cz... Karel PS. Thanks for redirect fix, www.postgresql.org is more nice :-) What happen with www.postgresql.org? My browser is always redirected to http://www.cz.postgresql.org/. But I haven't some terrible mirror (with last change "July 1999"), I want nice and native PG's web! :-) Karel PS. Exist some check what happen at PostgreSQL mirrors? The www.cz.postgresql.org is *discredit*... (sorry Czech friends). -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] Re: [BUGS] grant/revoke bug with delete/update
I tried to apply this patch to the current tree, but unfortunately,
changes made in permission handling prevent it from being applied.
Seems we were too far into testing to apply this long ago, and now we
are too far away from the original patch to apply it now. If you are
still intersted, we would like to get this patch against the current
source tree.
Sorry this got lost in the patch process for so long.
Hi,
first I'm sorry to not fill the form, I'm too lazy, and it's not platform
nor version dependent AFAIK.
I recently posted a question (on Feb 23rd) to pgsql-sql concerning the
fact that update and insert are considered the same thing when you modify
permissions with grant and revoke. (Maybe it was the wrong place to post
it.)
for example a "grant delete" also grants "update" which is completely
wrong. More importantly the user is not informed, and this could lead to
VERY IMPORTANT SECURITY PROBLEMS, like someone who should only be able to
update existing records, have the permission to delete all records...
I've read postgresql documentation, especially the grant and revoke
manpages, and I've found no mention of this bug, which is IMHO a Big
Mistake (tm).
attached to this message you'll find a patch for version 6.5.2 wich
differentiate delete and update, because before they were considered as
"write". The patch only modifies .c .y and .h files, but no documentation.
the new acl rights look like: arRdu
a for append
r for read
R for rules
d for delete
u for update
instead of: arwR
a for append
r for read
w for update AND delete
R for rules
This patch seems to work at least with what I've tested, you'll find a
test session at the end of this message.
I hope this patch will help and that it will be easy to incorporate it in
7.0, which I haven't the time to do for now.
And for the bug report I posted on Feb 23rd on "drop user" which keeps the
user's acl in the database, and the deleted user id being reused, I've not
done anything, but I consider this a major problem. Please consider it for
a next version.
Because I'm not an expert, I suggest you remove gram.c before applying the
patch, in order for this file to be generated again from gram.y, but maybe
this is not necessary.
I'd be very pleased if some people could test this more than I can,
because I don't use postgresql intensively with special permissions.
I'm not sure for some parts of the patch, especially in execMain.c
so if a postgresql hacker could examine it, this would be fine.
dump of test session:
-
--- CUT ---
template1= create database db;
CREATEDB
template1= create user john;
CREATE USER
template1= \connect db
connecting to new database: db
db= create table t (id INT4, name TEXT);
CREATE
db= \z
Database= db
+--+--+
| Relation | Grant/Revoke Permissions |
+--+--+
| t| |
+--+--+
db= grant all on t to john;
CHANGE
db= \z
Database= db
+--+--+
| Relation | Grant/Revoke Permissions |
+--+--+
| t| {"=","john=arduR"} |
+--+--+
db= \connect db john
connecting to new database: db as user: john
db= insert into t (id, name) values (1, 'xxx');
INSERT 18560 1
db= update t set name = 'yyy' where id=1;
UPDATE 1
db= select * from t;
id|name
--+
1|yyy
(1 row)
db= delete from t;
DELETE 1
db= select * from t;
id|name
--+
(0 rows)
db= insert into t (id, name) values (1, 'xxx');
INSERT 18561 1
db= \connect db postgres
connecting to new database: db as user: postgres
db= revoke update on t from john;
CHANGE
db= \z
Database= db
+--+--+
| Relation | Grant/Revoke Permissions |
+--+--+
| t| {"=","john=ardR"}|
+--+--+
db= \connect db john;
connecting to new database: db as user: john
db= insert into t (id, name) values (2, 'yyy');
INSERT 18592 1
db= update t set name='modified by john' where id=2;
ERROR: t: Permission denied.
db= delete from t where id=2;
DELETE 1
db= select * from t;
id|name
--+
1|xxx
(1 row)
db= \connect db postgres
connecting to new database: db as user: postgres
db= revoke insert on t from john;
CHANGE
db= \connect db john;
connecting to new database: db as user: john
db= \z
Database= db
+--+--+
| Relation | Grant/Revoke Permissions |
+--+--+
| t| {"=","john=rdR"} |
+--+--+
db= insert into t (id, name) values (3, 'I try to insert something');
ERROR: t: Permission denied.
db= delete from t;
DELETE 1
db= select * from t;
id|name
--+
(0
Re: [HACKERS] libpq PGHOST
Tom Lane writes: The current behaviour of libpq is to use Unix sockets whenever the host parameter (PGHOST or setdbLogin argument) is NULL/unset. Could we extend that to also use Unix sockets if the parameter is set but empty? Seems reasonable, since the current behavior in that case is useless: $ PGHOST='' psql psql: connectDBStart() -- unknown hostname: $ Backwards compatibility with that doesn't seem necessary ... After further investigation, there seems to be a larger unset/empty mess. When using PQconnectdb(), a NULL parameter (keyword was not given at all) means to use the environment variable, an explicit empty argument is used as is. When using PGsetdbLogin(), however both NULL and empty arguments cause the environment variable to be used. (An environment variable is always used as is.) Consequently, if PGHOST is set in the environment and your application is using PGsetdbLogin(), then it's just impossible to get a Unix socket connection. (Note that this is independent of the proposed change, because PGHOST may be set to some "real" string that you might wish to override.) If we were to sort this out, then I think we'd need to change PQsetdbLogin() to take empty arguments uniformly "as is", and make the change to make Unix sockets also with an empty host parameter, as proposed. Then you could use psql -h '' to request a Unix socket explicitly. Somewhat related: peter=# create function "" () returns int as 'select 42' language 'sql'; CREATE peter=# select ""(); 42 (1 row) That was probably not the plan. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] off-topic: (sorta) freebsd - oracle, lightweight
i need to query some oracle tables from a freebsd system. is there a lightweight method to do this, or do i have no choice but to put in the Oracle Linux stuff and use their API's? -- [ Jim Mercer [EMAIL PROTECTED] +1 416 410-5633 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]
Re: [HACKERS] libpq PGHOST
Peter Eisentraut [EMAIL PROTECTED] writes: If we were to sort this out, then I think we'd need to change PQsetdbLogin() to take empty arguments uniformly "as is", and make the change to make Unix sockets also with an empty host parameter, as proposed. Then you could use psql -h '' to request a Unix socket explicitly. Seems reasonable. peter=# create function "" () returns int as 'select 42' language 'sql'; CREATE peter=# select ""(); 42 (1 row) That was probably not the plan. I don't see any clear statement in SQL92 that delimited identifiers can't have zero length, so I'm not convinced there's anything wrong here. regards, tom lane
[HACKERS] What's happening with pgsql-committers?
Has anybody been getting pgsql-committers messages the last few days? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] off-topic: (sorta) freebsd - oracle, lightweight
I think it's against the Oracle license to run it under any kind of emulation (which is what you would have to do with FreeBSD, run it under Linux emulation).. All that's void if they support FreeBSD natively now (which I don't think they do).. Wouldn't this be a better question for an Oracle list since this has nothing to do with PostgreSQL? (Just a friendly suggestion) :-) Good luck!! -Mitch - Original Message - From: "Jim Mercer" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 02, 2000 12:43 PM Subject: [HACKERS] off-topic: (sorta) freebsd - oracle, lightweight i need to query some oracle tables from a freebsd system. is there a lightweight method to do this, or do i have no choice but to put in the Oracle Linux stuff and use their API's? -- [ Jim Mercer [EMAIL PROTECTED] +1 416 410-5633 ] [ Reptilian Research -- Longer Life through Colder ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True ode. ]
Re: [HACKERS] What's happening with pgsql-committers?
Hi Peter, I'm getting COMMITTERS OK but last week I noticed I wasn't getting HACKERS any more. Try sending a "show [EMAIL PROTECTED]" in the body of a message to [EMAIL PROTECTED] to see if you're still subscribed. Keith. --
[HACKERS] more crashes
This time I'm pretty sure I caught the initial crash during an update: I disabled the vacuum analyze and still got table corruption with a crash: two crashdumps of 7.0.2+somepatches *$Header: /home/pgcvs/pgsql/src/backend/access/common/heaptuple.c,v 1.6 2 2000/04/12 17:14:36 momjian Exp $ Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libcrypt.so.2...done. Reading symbols from /usr/lib/libm.so.2...done. Reading symbols from /usr/lib/libutil.so.3...done. Reading symbols from /usr/lib/libreadline.so.4...done. Reading symbols from /usr/lib/libncurses.so.5...done. Reading symbols from /usr/lib/libc.so.4...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. #0 0x8063aa7 in nocachegetattr (tuple=0x84ae9fc, attnum=4, tupleDesc=0x84a6368, isnull=0x84afc20 "") at heaptuple.c:537 537 off = att_addlength(off, att[i]-attlen, tp + off); (gdb) bt #0 0x8063aa7 in nocachegetattr (tuple=0x84ae9fc, attnum=4, tupleDesc=0x84a6368, isnull=0x84afc20 "") at heaptuple.c:537 #1 0x80a027f in ExecEvalVar (variable=0x84974b0, econtext=0x84aedd8, isNull=0x84afc20 "") at execQual.c:314 #2 0x80a0d97 in ExecEvalExpr (expression=0x84974b0, econtext=0x84aedd8, isNull=0x84afc20 "", isDone=0xbfbfe6db "\001ØíJ\b+ù\021\b\004èJ\b\001") at execQual.c:1214 #3 0x80a090a in ExecEvalFuncArgs (fcache=0x84afc38, econtext=0x84aedd8, argList=0x84974d8, argV=0xbfbfe6dc, argIsDone=0xbfbfe6db "\001ØíJ\b+ù\021\b\004èJ\b\001") at execQual.c:635 #4 0x80a09c1 in ExecMakeFunctionResult (node=0x8496a40, arguments=0x84974d8, econtext=0x84aedd8, isNull=0xbfbfe7db "", isDone=0xbfbfe75b "\b\214ç¿¿\027\016\n\bHuI\bØíJ\bÛç¿¿X\017B`\004") at execQual.c:711 #5 0x80a0b37 in ExecEvalOper (opClause=0x8497548, econtext=0x84aedd8, isNull=0xbfbfe7db "") at execQual.c:902 #6 0x80a0e17 in ExecEvalExpr (expression=0x8497548, econtext=0x84aedd8, isNull=0xbfbfe7db "", isDone=0xbfbfe7e0 "\001É\016\b") at execQual.c:1249 #7 0x80a1011 in ExecTargetList (targetlist=0x8497fd8, nodomains=6, targettype=0x84aefb0, values=0x84aee48, econtext=0x84aedd8, isDone=0xbfbfe90b "\001,é¿¿.K\n\bPÝJ\b\214H\n\bé¿¿çA\023\b\030ÀH\b ") at execQual.c:1511 #8 0x80a12af in ExecProject (projInfo=0x84aee20, isDone=0xbfbfe90b "\001,é¿¿.K\n\bPÝJ\b\214H\n\bé¿¿çA\023\b\030ÀH\b ") at execQual.c:1721 #9 0x80a1365 in ExecScan (node=0x84add50, accessMtd=0x80a488c IndexNext) at execScan.c:155 #10 0x80a4b2e in ExecIndexScan (node=0x84add50) at nodeIndexscan.c:288 #11 0x809fb6d in ExecProcNode (node=0x84add50, parent=0x84add50) at execProcnode.c:272 #12 0x809ed59 in ExecutePlan (estate=0x84ae8a0, plan=0x84add50, operation=CMD_UPDATE, offsetTuples=0, numberTuples=0, direction=ForwardScanDirection, destfunc=0x84afaf0) at execMain.c:1052 #13 0x809e2ba in ExecutorRun (queryDesc=0x84ae888, estate=0x84ae8a0, feature=3, limoffset=0x0, limcount=0x0) at execMain.c:327 #14 0x80f92ca in ProcessQueryDesc (queryDesc=0x84ae888, limoffset=0x0, limcount=0x0) at pquery.c:310 #15 0x80f9347 in ProcessQuery (parsetree=0x84965d0, plan=0x84add50, dest=Remote) at pquery.c:353 #16 0x80f7ef0 in pg_exec_query_dest ( query_string=0x81a9370 "\nUPDATE\n webhit_details_formatted\nSET\n attr_hits = attr_hits + '1' \nWHERE\n counter_id = '11909'\n AND attr_type = 'ATTR_OPERATINGSYS'\n AND attr_name = 'win95'\n AND attr_vers = '0'\n;", dest=Remote, aclOverride=0) at postgres.c:663 #17 0x80f7db9 in pg_exec_query ( query_string=0x81a9370 "\nUPDATE\n webhit_details_formatted\nSET\n attr_hits = attr_hits + '1' \nWHERE\n counter_id = '11909'\n AND attr_type = 'ATTR_OPERATINGSYS'\n AND attr_name = 'win95'\n AND attr_vers = '0'\n;") at postgres.c:562 #18 0x80f8d1a in PostgresMain (argc=9, argv=0xbfbff0dc, real_argc=10, real_argv=0xbfbffb3c) at postgres.c:1590 #19 0x80e1d06 in DoBackend (port=0x843f400) at postmaster.c:2009 #20 0x80e1899 in BackendStartup (port=0x843f400) at postmaster.c:1776 #21 0x80e0abd in ServerLoop () at postmaster.c:1037 #22 0x80e04be in PostmasterMain (argc=10, argv=0xbfbffb3c) at postmaster.c:725 #23 0x80aee43 in main (argc=10, argv=0xbfbffb3c) at main.c:93 #24 0x80633c5 in _start () (gdb) list 532 533 if (usecache) 534 att[i]-attcacheoff = off; 535 } 536 537 off = att_addlength(off, att[i]-attlen, tp + off); 538 539 if (usecache 540 att[i]-attlen == -1 !VARLENA_FIXED_SIZE(att[i])) 541 usecache = false; (gdb) print off $1 = 772814392 (gdb) print att[i]-attlen $2 = -1 (gdb) print off $3 = 772814392 (gdb) print tp $4 = 0x5eab73d0 "\205." (gdb) print tp+off $7 = 0x8cbbaa08 Address 0x8cbbaa08 out of bounds (gdb) print usecache $8 = 0 '\000'
Re: [HACKERS] off-topic: (sorta) freebsd - oracle, lightweight
I have absolutely no idea how well it works, but I think Perl/DBI has a "pass thru" module that can do this sort of thing... not sure if that helps much... -philip On Mon, 2 Oct 2000, Jim Mercer wrote: i need to query some oracle tables from a freebsd system. is there a lightweight method to do this, or do i have no choice but to put in the Oracle Linux stuff and use their API's? -- [ Jim Mercer [EMAIL PROTECTED] +1 416 410-5633 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]
Re: [HACKERS] Suggested change in include/utils/elog.h
Magnus Hagander wrote: If you do decide to prefix DEBUG, please consider prefixing at least ERROR as well. It produces a lot of warnings when compiling on Win32 (ERROR is already defined as part of the standard windows headers). It's just warnings, though. //Magnus Do other people have a comment on this. I am inclined to leave it along. This is the first complaint I have heard, and elog(PGDEBUG) just looks funny. We don't prefix NOTICE or ERROR. In the file include/utils/elog.h there is a macro named DEBUG that conflicts with the perl5.6 macro DEBUG. PostgreSQL would probably "play" better with other products if the DEBUG macro had a prefix, maybe PGSQLDEBUG or similar. Until there is some fix in this area, plperl will not build with a version of perl that has debugging enabled. It even got on my nerves (linux, ecpg) since I used to define a macro #define DEBUG(x) cout x or #define DEBUG(x) DEBUG and ERROR are far too common to get defined for client programs. But perhaps it is ecpg's fault for including "elog.h". IMHO these defines should never leave the database kernel. perhaps the common #ifdef _DBKERNEL_ #endif would do the trick. Christof PS: Having Datum unconditionally leaked to ecpg programs forced me to preced a namespace to my own class.
Re: [HACKERS] Adding time to DATE type
Is this something worth addressing? Peter Eisentraut [EMAIL PROTECTED] writes: Bruce Momjian writes: Can someone give me a TODO summary for this issue? * make 'text' constants default to text type (not unknown) (I think not everyone's completely convinced on this issue, but I don't recall anyone being firmly opposed to it.) It would be a mistake to eliminate the distinction between unknown and text. See for example my just-posted response to John Cochran on pgsql-general about why 'BOULEVARD'::text behaves differently from 'BOULEVARD'::char. If string literals are immediately assigned type text then we will have serious problems with char(n) fields. I think it's fine to assign string literals a type of 'unknown' initially. What we need to do is add a phase of type resolution that considers treating them as text, but only after the existing logic fails to deduce a type. (BTW it might be better to treat string literals as defaulting to char(n) instead of text, allowing the normal promotion rules to replace char(n) with text if necessary. Not sure if that would make things more or less confusing for operations that intermix fixed- and variable-width char types.) regards, tom lane -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Patch for 'Not to stuff everything as files in a singledirectory, hash dirs''
My idea was to implement the large object API on top of TOAST. Bruce Momjian wrote: Seems the whole large object per file is going away in 7.1. Can someone confirm this? Not the whole one in 7.1. The TOAST stuff will lower the need for large objects alot, but we already discovered the fact that it isn't a real answer to LARGE objects. First of all, the entire datum must be properly quoted to fit into a querystring. Therefore the client needs to have the original datum, the qouted copy, the querystring it built. Then the querystring is sent to the backend, parsed (where a CONST node is built from it), copied into a tuple to be split up into TOAST items. So on a central system, where client and DB are both running, we have 6 copies of the object in memory! Not that optimal. For 7.2 I'll work on real CLOB and BLOB data types. Requires some more thinking though. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] What's happening with pgsql-committers?
Peter Eisentraut [EMAIL PROTECTED] writes: Has anybody been getting pgsql-committers messages the last few days? Coming through fine for me (at least when hub.org isn't wedged completely, which it was several times over the weekend...) regards, tom lane
Re: [HACKERS] Proposal: TRUNCATE TABLE table RESTRICT
Can someone comment on this? It seems the truncate command deletes all rows from a table even it is referenced by another tables. TRUNCATE is not in the standard any way, so I would not claim this is a bug. However, sometimes it would be helpful for a user to let him notice that the table about to be truncated is referenced by some tables. So I would propose to add "RESTRICT" option to the command. I mean if RESTRICT is specified, TRUNCATE will fail if the table is referenced. BTW, the keyword "RESTRICT" is inspired by the fact that DROP TABLE has the same option according to the standard. If a table is referenced by some tables and the drop table command has the RESTRICT option, it would fail. This seems to be a nice feature too. Comments? -- Tatsuo Ishii -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
