[HACKERS] setuid functions
Hello, i searched around about privileges for functions, but it seems, that there is nothing available in the 7.2.x series. So my question: Is it possible to execute a function (in this case a C function) with permissions of the function creater instead of the user who's actual using function? Best regards -- Andreas 'ads' Scherbaum ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [Fwd: AW: More UB-Tree patent information]
Patents are as much designed to confuse and dissuade someone from using something as they are to patent something. Reading a patent is often harder than killing the nearest chicken, strewing it's entrails allover the yard, and then trying to make some sense of it. Justin Clift wrote: Hannu Krosing wrote: On Wed, 2002-04-10 at 16:32, Justin Clift wrote: Hi everyone, This is Prof. Bayer's response to the question is it alright to use UB-Tree's in Open Source projects?. Have you found out _what_ exaclty is patented ? Is it just his concrete implementation of UB-Tree or something broader, like using one multi-dimensional index instead of multiple one-dimensional ones ? Is there any way of finding out instead of asking him directly? Maybe the patent places have online info? Professor Bayer isn't being overly informative. Anyone know? :-) Regards and best wishes, Justin Clift - Hannu ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [Fwd: AW: More UB-Tree patent information]
On Wed, 2002-04-10 at 21:55, Justin Clift wrote: Hannu Krosing wrote: On Wed, 2002-04-10 at 16:32, Justin Clift wrote: Hi everyone, This is Prof. Bayer's response to the question is it alright to use UB-Tree's in Open Source projects?. Have you found out _what_ exaclty is patented ? Is it just his concrete implementation of UB-Tree or something broader, like using one multi-dimensional index instead of multiple one-dimensional ones ? Is there any way of finding out instead of asking him directly? Maybe the patent places have online info? I did a quick search at USPTO at http://patft.uspto.gov/netahtml/search-bool.html on UB and Tree and index and database and found among other things a US patent no. 5,826,253 on mechanism very similar to LISTEN/NOTIFY, afforded to Borland on October 20, 1998 based on application from April 19, 1996. We should be safe as already Postgres95 had them ;) when I searched for UB and Tree and index and database and Bayer 0 results came back. when I omitted UB and searched for Tree and index and database and Bayer I got 27 results, first of them on Method and composition for improving sexual fitness ;) the one possibly related related to our Bayer was nr 6,219,662 on Supporting database indexes based on a generalized B-tree index which had reference to : Rudolf Bayer, The Universal B-Tree for Multidimensional Indexing: General Concepts, Worldwide Computing and Its Applications, International Conference, WWCA '97, Tsukuba, Japan, (Mar. 1997), pp. 198-209. and German patent 0 650 131 A1 which may be also relevant -- Hannu ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] RFC: Restructuring pg_aggregate
Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: Tom Lane wrote: That means that a lot of low-level places *do* need to know about the dropped-column convention, else they can't make any sense of tuple layouts. Why ? As you already mentioned, there were not that many places to be changed. There are not many places to change if the implementation uses attisdropped, because we *only* have to hide the existence of the column at the parser level. The guts of the system don't know anything funny is going on; a dropped column looks the same as an undropped one throughout the executor. But with negative attnums, even such basic routines as heap_formtuple have to know about it, no? When a tuple descriptor is made, the info of dropped columns are placed at (their physical position - 1) index in the same way as ordinary columns. There are few places where conversions between negative attnums and the physical positions are needed. The following is my posting more than 2 years ago. What's changed since then. regards, Hiroshi Inoue I don't want a final implementation this time. What I want is to provide a quick hack for both others and me to judge whether this direction is good or not. My idea is essentially an invisible column implementation. DROP COLUMN would change the target pg_attribute tuple as follows.. attnum - an offset - attnum; atttypid - 0 We would be able to see where to change by tracking error/ crashes caused by this change. I would also change attname to '*already dropped %d' for examle to avoid duplicate attname. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] RFC: Restructuring pg_aggregate
Bruce Momjian wrote: Hiroshi Inoue wrote: Tom Lane wrote: Hiroshi's "DROP_COLUMN_HACK" was essentially along this line, but I think he made a representational mistake by trying to change the attnums of dropped columns to be negative values. Negative attnums had 2 advantages then. It had a big advantage that initdb isn't needed. Note that it was only a trial hack and there was no consensus on the way. It was very easy to change the implementation to use attisdropped. OTOH physical/logical attnums approach needed the change on pg_class, pg_attribute and so I've never had a chance to open the patch to public. It was also more sensitive about oversights of needed changes than the attisdropped flag approach. That means that a lot of low-level places *do* need to know about the dropped-column convention, else they can't make any sense of tuple layouts. Why ? As you already mentioned, there were not that many places to be changed. Well what's changed since then ? Here is an old email from me that outlines the idea of having a physical/logical attribute numbering system, and the advantages. I already tried physical/logical attribute implementation pretty long ago. Where are new ideas to solve the problems that the approach has ? regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RFC: Restructuring pg_aggregate
Hiroshi Inoue wrote: Why ? As you already mentioned, there were not that many places to be changed. Well what's changed since then ? Here is an old email from me that outlines the idea of having a physical/logical attribute numbering system, and the advantages. I already tried physical/logical attribute implementation pretty long ago. Where are new ideas to solve the problems that the approach has ? Good question. I am suggesting more than just the drop column fix. It could be used for smaller data files to reduce padding, fix for inheritance problems with ADD COLUMN, and performance of moving varlena's to the end of the row. Also, my idea was to have the physical/logical mapping happen closer to the client, so the backend mostly only deals with physical. I was thinking of having the libpq backend communication layer actually do the reordering of the return results. -- 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] UNSUSCRIBE pgsql_hackers
__ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Odd error during vacuum
Hi all, I got these odd messages while doing a vacuum in 7.1.3 0 - any idea what they mean? I assume it's not fatal as they're just notices, but I've never had them before and haven't had them since. NOTICE: RegisterSharedInvalid: SI buffer overflow NOTICE: InvalidateSharedInvalid: cache state reset Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Odd error during vacuum
On Thu, 11 Apr 2002, Christopher Kings-Lynne wrote: Hi all, I got these odd messages while doing a vacuum in 7.1.3 0 - any idea what they mean? I assume it's not fatal as they're just notices, but I've never had them before and haven't had them since. NOTICE: RegisterSharedInvalid: SI buffer overflow NOTICE: InvalidateSharedInvalid: cache state reset This just means that the cache invalidation buffer got overloaded and was reset. Its not really a problem (except in terms of performance). I would say that if you haven't seen this before your database is getting more usage and/or more data. To fix this increase shared_buffers. Gavin ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] help with bison
Neil Conway [EMAIL PROTECTED] writes: Unfortunately, bison isn't very helpful: it doesn't provide line-numbers when it warns me about the # of conflicts. Run bison with -v switch (thus, bison -y -d -v gram.y) and look at the y.output file it produces. More detail than you really wanted ;-) regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Odd error during vacuum
Gavin Sherry [EMAIL PROTECTED] writes: NOTICE: RegisterSharedInvalid: SI buffer overflow NOTICE: InvalidateSharedInvalid: cache state reset To fix this increase shared_buffers. AFAIK shared_buffers has no direct effect on the rate of SI overruns. I suppose it might have an indirect effect just by improving overall performance... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] help with bison
I don't see in this patch that you've added your new keywords to any of the lists of reserved words towards the bottom of gram.y. Have a look down and see the lists. You need to add the keywords to the first list in the file that doesn't give a shift/reduce error. (ie. make the words the least reserved as possible.) Also, make sure you've put them in keywords.c as well. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Neil Conway Sent: Thursday, 11 April 2002 9:29 AM To: PostgreSQL Hackers Subject: [HACKERS] help with bison Hi all, I'm working on a fairly large patch (cleaning up Karel Zak's PREPARE/EXECUTE work), and I'm having some problems with bison (I'm a yacc newbie). In fact, my grammar currently has an obscene 20 shift/reduce and 4 reduce/reduce conflicts! Would someone to be kind enough to let me know what I'm doing wrong, and what I'll need to change? (Unfortunately, bison isn't very helpful: it doesn't provide line-numbers when it warns me about the # of conflicts). The patch for gram.y is below. Thanks in advance, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC Index: gram.y === RCS file: /var/lib/cvs/pgsql/src/backend/parser/gram.y,v retrieving revision 2.299 diff -c -r2.299 gram.y *** gram.y1 Apr 2002 04:35:38 - 2.299 --- gram.y11 Apr 2002 01:26:21 - *** *** 133,144 ClosePortalStmt, ClusterStmt, CommentStmt, ConstraintsSetStmt, CopyStmt, CreateAsStmt, CreateDomainStmt, CreateGroupStmt, CreatePLangStmt, CreateSchemaStmt, CreateSeqStmt, CreateStmt, CreateTrigStmt, ! CreateUserStmt, CreatedbStmt, CursorStmt, DefineStmt, DeleteStmt, ! DropGroupStmt, DropPLangStmt, DropSchemaStmt, DropStmt, DropTrigStmt, ! DropUserStmt, DropdbStmt, ExplainStmt, FetchStmt, GrantStmt, IndexStmt, InsertStmt, ListenStmt, LoadStmt, LockStmt, ! NotifyStmt, OptimizableStmt, ProcedureStmt, ReindexStmt, ! RemoveAggrStmt, RemoveFuncStmt, RemoveOperStmt, RenameStmt, RevokeStmt, RuleActionStmt, RuleActionStmtOrEmpty, RuleStmt, SelectStmt, TransactionStmt, TruncateStmt, UnlistenStmt, UpdateStmt, VacuumStmt, VariableResetStmt, --- 133,145 ClosePortalStmt, ClusterStmt, CommentStmt, ConstraintsSetStmt, CopyStmt, CreateAsStmt, CreateDomainStmt, CreateGroupStmt, CreatePLangStmt, CreateSchemaStmt, CreateSeqStmt, CreateStmt, CreateTrigStmt, ! CreateUserStmt, CreatedbStmt, CursorStmt, DeallocatePrepareStmt, ! DefineStmt, DeleteStmt, DropGroupStmt, ! DropPLangStmt, DropSchemaStmt, DropStmt, DropTrigStmt, ! DropUserStmt, DropdbStmt, ExecuteStmt, ExplainStmt, FetchStmt, GrantStmt, IndexStmt, InsertStmt, ListenStmt, LoadStmt, LockStmt, ! NotifyStmt, OptimizableStmt, ProcedureStmt, PrepareStmt, prepare_query, ! ReindexStmt, RemoveAggrStmt, RemoveFuncStmt, RemoveOperStmt, RenameStmt, RevokeStmt, RuleActionStmt, RuleActionStmtOrEmpty, RuleStmt, SelectStmt, TransactionStmt, TruncateStmt, UnlistenStmt, UpdateStmt, VacuumStmt, VariableResetStmt, *** *** 204,210 any_name, any_name_list, expr_list, dotted_name, attrs, target_list, update_target_list, insert_column_list, def_list, opt_indirection, group_clause, TriggerFuncArgs, ! select_limit, opt_select_limit %type range into_clause, OptTempTableName --- 205,214 any_name, any_name_list, expr_list, dotted_name, attrs, target_list, update_target_list, insert_column_list, def_list, opt_indirection, group_clause, TriggerFuncArgs, ! select_limit, opt_select_limit, types_list, ! types_prepare_clause, execute_using ! ! %type ivalprepare_store %type range into_clause, OptTempTableName *** *** 319,325 COALESCE, COLLATE, COLUMN, COMMIT, CONSTRAINT, CONSTRAINTS, CREATE, CROSS, CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP, CURRENT_USER, CURSOR, ! DAY_P, DEC, DECIMAL, DECLARE, DEFAULT, DELETE, DESC, DISTINCT, DOUBLE, DROP, ELSE, ENCRYPTED, END_TRANS, ESCAPE, EXCEPT, EXECUTE, EXISTS, EXTRACT, FALSE_P, FETCH, FLOAT, FOR, FOREIGN, FROM, FULL, --- 323,329 COALESCE, COLLATE, COLUMN, COMMIT, CONSTRAINT, CONSTRAINTS, CREATE, CROSS, CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP, CURRENT_USER, CURSOR, ! DAY_P, DEALLOCATE, DEC, DECIMAL, DECLARE, DEFAULT, DELETE, DESC,
Re: [HACKERS] help with bison
In fact, my grammar currently has an obscene
20 shift/reduce and 4 reduce/reduce conflicts!
A shift/reduce conflict, IIRC, usually indicates a situation where
the grammar is unambiguous but may be inefficient. Eliminating them
is nice, but not critical.
A R/R conflict, in contrast, is a point where the grammar is ambiguous
and you *must* fix it.
(Unfortunately, bison isn't very
helpful: it doesn't provide line-numbers when it warns me about
the # of conflicts).
Turn on the verbose flag (-v|--verbose). Near the top it should
list the S/R and R/R states. You can then examine the states and
rules and see exactly where the problem is.
Cutting to the chase, the R/R problems are due to TEMP and
TEMPORARY being both unreserved keywords and part of
OptTempTableName. If you comment them out in 'unreserved keywords'
the R/R error goes away but this may introduce errors elsewhere.
What is probably better is to move those tokens someplace else
where there's some context:
into_clause : INTO OptTempTableName
| /* EMPTY */
;
needs to be replaced with something like
into_options : /* EMPTY */
| TEMPORARY
| TEMP
;
into_clause : INTO into_options OptTempTableName
| /* EMPTY */
;
with the corresponding modifiers removed from the OptTempTableName
Unfortunately, when I quickly tested that the number of S/R conflicts
ballooned to 378.
As an aside, is there any reason to treat TEMP and TEMPORARY as two
separate identifiers? It's common practice to have synonyms mapped
to a single identifier in the lexical analyzer, and the grammar itself
looks like it could benefit from some helper rules such as:
temporary
: TEMPORARY { $$ = 1; }
| TEMP { $$ = 1; }
|{ $$ = 0; }
;
scope
: GLOBAL { $$ = 1; }
| LOCAL { $$ = 2; }
|{ $$ = 0; }
;
something : scope temporary somethingelse { ... }
Bear
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] help with bison
Out of interest, since the FE/BE protocol apprently doesn't support prepared statements (bound variables), what does this patch actually _do_? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Neil Conway Sent: Thursday, 11 April 2002 9:29 AM To: PostgreSQL Hackers Subject: [HACKERS] help with bison Hi all, I'm working on a fairly large patch (cleaning up Karel Zak's PREPARE/EXECUTE work), and I'm having some problems with bison (I'm a yacc newbie). In fact, my grammar currently has an obscene 20 shift/reduce and 4 reduce/reduce conflicts! Would someone to be kind enough to let me know what I'm doing wrong, and what I'll need to change? (Unfortunately, bison isn't very helpful: it doesn't provide line-numbers when it warns me about the # of conflicts). The patch for gram.y is below. Thanks in advance, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] BETWEEN SYMMETRIC/ASYMMETRIC
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Also, Tom (or anyone): in regards to your previous email, should I just go back to using opt_symmetry to shorten the number of productions, since I have to make them reserved words anyway? Might as well. No point in writing more productions if it doesn't buy anything. Since it's really just two ways of writing the same thing, wouldn't bison just produce the exact same C code? I'll rewrite it anyway for elegance, but just wondering... BTW, I've forgotten whether your patch is purely syntactic or not, but I'd really like to see someone fix things so that BETWEEN has its own expression node tree type and is not expanded into some ugly A=B and A=C equivalent. This would (a) allow it to be reverse-listed reasonably, and (b) eliminate redundant evaluations of the subexpressions. It is purely syntactic. Anyone want to give me a quick hint on how to make a new node tree type for BETWEEN? What does reverse-listing mean as well? Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] help with bison
On Thu, 11 Apr 2002 10:54:14 +0800 Christopher Kings-Lynne [EMAIL PROTECTED] wrote: Out of interest, since the FE/BE protocol apprently doesn't support prepared statements (bound variables), what does this patch actually _do_? It implements preparable statements, by adding 3 new SQL statements: PREPARE plan AS query; EXECUTE plan USING parameters; DEALLOCATE plan; I didn't write the original patch -- that was done by Karel Zak. But since that was several years ago, I'm working on cleaning it up, getting it to apply to current sources (which has taken a while), and fixing the remaining issues with it. Karel describes his work here: http://groups.google.com/groups?q=query+cache+planhl=enselm=8l4jua%242fo0%241%40FreeBSD.csie.NCTU.edu.twrnum=1 (If that's messed up due to newlines, search for query cache plan on Google Groups, it's the first result) Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] BETWEEN SYMMETRIC/ASYMMETRIC
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Since it's really just two ways of writing the same thing, wouldn't bison just produce the exact same C code? I'll rewrite it anyway for elegance, but just wondering... The emitted code might or might not be the same --- but duplicate or near-duplicate chunks of source code are always best avoided, if only from a maintenance perspective. BTW, I've forgotten whether your patch is purely syntactic or not, but I'd really like to see someone fix things so that BETWEEN has its own expression node tree type and is not expanded into some ugly A=B and A=C equivalent. This would (a) allow it to be reverse-listed reasonably, and (b) eliminate redundant evaluations of the subexpressions. It is purely syntactic. Anyone want to give me a quick hint on how to make a new node tree type for BETWEEN? Try chasing the references to another extant expression node type, perhaps NullTest. It's fairly straightforward, but tedious to teach all the relevant places about it. What does reverse-listing mean as well? reverse-listing is what src/backend/utils/adt/ruleutils.c does: produce something readable from an internal node tree. \d for a view, pg_dump, and other useful things depend on this. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] help with bison
Bear Giles [EMAIL PROTECTED] writes: As an aside, is there any reason to treat TEMP and TEMPORARY as two separate identifiers? Yes: if the lexer folds them together then unreserved_keyword can't regenerate the equivalent name properly. (Possibly this could be fixed by making the lexer pass the input string as the value of a keyword token, but I've not looked at details.) You might be right that the grammar could benefit from some refactoring, though I'm not at all sure if that really helps from an execution-efficiency (number of states) standpoint. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RFC: Restructuring pg_aggregate
Bruce Momjian wrote: Hiroshi Inoue wrote: Why ? As you already mentioned, there were not that many places to be changed. Well what's changed since then ? Here is an old email from me that outlines the idea of having a physical/logical attribute numbering system, and the advantages. I already tried physical/logical attribute implementation pretty long ago. Where are new ideas to solve the problems that the approach has ? Good question. I am suggesting more than just the drop column fix. It could be used for smaller data files to reduce padding, fix for inheritance problems with ADD COLUMN, and performance of moving varlena's to the end of the row. Also, my idea was to have the physical/logical mapping happen closer to the client, so the backend mostly only deals with physical. If the client has to bear the some part, isn't the invisible column approach much simpler ? I've put a pretty much time into DROP COLUMN feature but I am really disappointed to see the comments in this thread. What DROP COLUMN has brought me seems only a waste of time. Possibly I must have introduced either implementation forcibly. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] RFC: Restructuring pg_aggregate
Hiroshi Inoue wrote: If the client has to bear the some part, isn't the invisible column approach much simpler ? I've put a pretty much time into DROP COLUMN feature but I am really disappointed to see the comments in this thread. What DROP COLUMN has brought me seems only a waste of time. Possibly I must have introduced either implementation forcibly. I understand. I personally think maybe we have been a little to picky about patches being accepted. Sometimes when something is not 100% perfect, we do nothing rather than accept the patch, and replace or improve it later. The DROP COLUMN approach you had clearly is one of them. Personally, now that we have relfilenode, I think we should implement drop of columns by just recreating the table without the column. The big problem with DROP COLUMN was that we couldn't decide on what to do, so we did nothing, which is probably worse than just choosing one and doing it. Our code is littered with my 80% solutions for LIKE optimization, optimizer statistics, BETWEEN, and lots of other solutions that have met a need and are now being replaced with better code. My code was not great, but I hadn't dont them, PostgreSQL would have had even more missing features than we do now. DROP COLUMN is clearly one where we missed getting something that works and would keep people happy. As far as my proposal, my idea was not to do it in the client, but rather to do it just before the data is sent from/to the client. Maybe that is a stupid idea. I never really researched it. My idea was more to make the physical/logical column numbers distinct so certain tricks could be performed. It wasn't for DROP COLUMN specifically, and in fact to do DROP COLUMN with my code, there would have to be more code similar to what you had where clients would see a column and have to skip it. I was focusing more on physical/logical to enable other features. -- 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] RFC: Restructuring pg_aggregate
Christopher Kings-Lynne wrote: If the client has to bear the some part, isn't the invisible column approach much simpler ? I've put a pretty much time into DROP COLUMN feature but I am really disappointed to see the comments in this thread. What DROP COLUMN has brought me seems only a waste of time. I kind of agree with Hiroshi here. All I want to be able to do is drop columns from my tables, and reclaim the space. I've got all sorts of production tables with columns just sitting there doing nothing, awaiting the time that I can happily drop them. It seems to me that whatever we do will require some kind of client breakage. Actually, what we need to do to reclaim space is to enable table recreation without the column, now that we have relfilenode for file renaming. It isn't hard to do, but no one has focused on it. I want to focus on it, but have not had the time, obviously, and would be very excited to assist someone else. Hiroshi's fine idea of marking certain columns as unused would not have reclaimed the missing space, just as my idea of physical/logical column distinction would not reclaim the space either. Again, my physical/logical idea is more for fixing other problems and optimization, not DROP COLUMN. -- 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 ---(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: [HACKERS] help with bison
Bear Giles [EMAIL PROTECTED] writes: Yes: if the lexer folds them together then unreserved_keyword can't regenerate the equivalent name properly. But if they're synonyms, is that necessary? If I say create table foo (temp int); I will be annoyed if the system decides that the column is named temporary. Being synonyms in the SQL grammar does not make them equivalent when used as plain identifiers. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] RFC: Restructuring pg_aggregate
Christopher Kings-Lynne wrote: Actually, what we need to do to reclaim space is to enable table recreation without the column, now that we have relfilenode for file renaming. It isn't hard to do, but no one has focused on it. I want to focus on it, but have not had the time, obviously, and would be very excited to assist someone else. I'm happy to help - depends if it's within my skill level or not tho. Most of the time the problem I have is finding where to make the changes, not actually making the changes themselves. So, count me in. OK, let me mention that I have had great success with chat sessions with PostgreSQL developers. They can code and ask questions and I can answer quickly. Seems to be speeding things along for some people. I am: AIM bmomjian ICQ 151255111 Yahoo bmomjian MSN [EMAIL PROTECTED] I am also on the PostgreSQL IRC channel. As far as where to start, I think the CLUSTER command would be a good start because it just reorders the existing table. Then DROP COLUMN can come out of that by removing the column during the copy, and removing mention of the column from pg_attribute, and of course renumbering the gap. Hiroshi's fine idea of marking certain columns as unused would not have reclaimed the missing space, just as my idea of physical/logical column distinction would not reclaim the space either. Again, my physical/logical idea is more for fixing other problems and optimization, not DROP COLUMN. Question: Is it _possible_ to reclaim the space during a VACUUM FULL? I do not know enough about the file format to know this. What happens if the VACUUM is stopped halfway thru reclaiming a column in a table? Not really. I moves only whole tuples, and only certain ones. Bruce: WRT modifying libpq to do the translation - won't this cause probs for JDBC and ODBC people? No, not in libpq, but rather in backend/libpq, the backend part of the connection. My idea is for the user to think things are in a different order in the row than they actually appear on disk. I haven't really researched it enough to understand its validity. -- 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RFC: Restructuring pg_aggregate
Christopher Kings-Lynne wrote: If the client has to bear the some part, isn't the invisible column approach much simpler ? I've put a pretty much time into DROP COLUMN feature but I am really disappointed to see the comments in this thread. What DROP COLUMN has brought me seems only a waste of time. I kind of agree with Hiroshi here. All I want to be able to do is drop columns from my tables, and reclaim the space. I've got all sorts of production tables with columns just sitting there doing nothing, awaiting the time that I can happily drop them. It seems to me that whatever we do will require some kind of client breakage. Physical/logical attnum approach was mainly to not break clients. I implemented it on trial but the implementation was hard to maintain unfortunately. It's pretty difficult to decide whether the number is physical or logical in many cases. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] RFC: Restructuring pg_aggregate
Hiroshi Inoue wrote: It seems to me that whatever we do will require some kind of client breakage. Physical/logical attnum approach was mainly to not break clients. I implemented it on trial but the implementation was hard to maintain unfortunately. It's pretty difficult to decide whether the number is physical or logical in many cases. How many cases do we have that use logical numering? Hiroshi, I know you are the expert on this. I know 'SELECT *' uses it, but are their other places that need to know about the logical ordering of the columns? -- 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 ---(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
[HACKERS] 7.3 schedule
Is anyone feeling we have the 7.3 release nearing? I certainly am not. I can imagine us going for several more months like this, perhaps through August. -- 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] RFC: Restructuring pg_aggregate
Bruce Momjian wrote: Hiroshi Inoue wrote: If the client has to bear the some part, isn't the invisible column approach much simpler ? I've put a pretty much time into DROP COLUMN feature but I am really disappointed to see the comments in this thread. What DROP COLUMN has brought me seems only a waste of time. Possibly I must have introduced either implementation forcibly. I understand. I personally think maybe we have been a little to picky about patches being accepted. Sometimes when something is not 100% perfect, we do nothing rather than accept the patch, and replace or improve it later. The DROP COLUMN approach you had clearly is one of them. I don't complain about the rejection of my patch. If it has an essential flaw we had better reject it. What I'm complaining is why it is OK now whereas there's nothing new. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RFC: Restructuring pg_aggregate
Hiroshi Inoue wrote: Bruce Momjian wrote: Hiroshi Inoue wrote: If the client has to bear the some part, isn't the invisible column approach much simpler ? I've put a pretty much time into DROP COLUMN feature but I am really disappointed to see the comments in this thread. What DROP COLUMN has brought me seems only a waste of time. Possibly I must have introduced either implementation forcibly. I understand. I personally think maybe we have been a little to picky about patches being accepted. Sometimes when something is not 100% perfect, we do nothing rather than accept the patch, and replace or improve it later. The DROP COLUMN approach you had clearly is one of them. I don't complain about the rejection of my patch. If it has an essential flaw we had better reject it. What I'm complaining is why it is OK now whereas there's nothing new. Sure, I understand. My physical/logical idea may have the same problems as your DROP COLUMN idea, and may be as rapidly rejected. I am just throwing it out for discussion. I am not sure I like it. :-) -- 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.3 schedule
Is anyone feeling we have the 7.3 release nearing? No way! I certainly am not. I can imagine us going for several more months like this, perhaps through August. Easily. I think that the critical path is Tom's schema support. We'll need a good beta period this time, because of: * Schemas * Prepare/Execute maybe * Domains Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.3 schedule
Christopher Kings-Lynne wrote: Is anyone feeling we have the 7.3 release nearing? No way! Good. I certainly am not. I can imagine us going for several more months like this, perhaps through August. Easily. I think that the critical path is Tom's schema support. We'll need a good beta period this time, because of: * Schemas * Prepare/Execute maybe * Domains I guess I am hoping for even more killer features for this release. -- 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Implicit coercions need to be reined in
Tom, My feeling is that this change as currently scoped will break a lot of existing apps. Especially the case where people are using where clauses of the form: bigintcolumn = '999' to get a query to use the index on a column of type bigint. thanks, --Barry Tom Lane wrote: Awhile back I suggested adding a boolean column to pg_proc to control which type coercion functions could be invoked implicitly, and which would need an explicit cast: http://archives.postgresql.org/pgsql-hackers/2001-11/msg00803.php There is a relevant bug report #484 showing the dangers of too many implicit coercion paths: http://archives.postgresql.org/pgsql-bugs/2001-10/msg00108.php I have added such a column as part of the pg_proc changes I'm currently doing to migrate aggregates into pg_proc. So it's now time to debate the nitty-gritty: exactly which coercion functions should not be implicitly invokable anymore? My first-cut attempt at this is shown by the two printouts below. The first cut does not allow any implicit coercions to text from types that are not in the text category, which seems a necessary rule to me --- the above-cited bug report shows why free coercions to text are dangerous. However, it turns out that several of the regression tests fail with this rule; see the regression diffs below. Should I consider these regression tests wrong, and correct them? If not, how can we limit implicit coercions to text enough to avoid the problems illustrated by bug #484? Another interesting point is that I allowed implicit coercions from float8 to numeric; this is necessary to avoid breaking cases like insert into foo(numeric_col) values(12.34); since the constant will be initially typed as float8. However, because I didn't allow the reverse coercion implicitly, this makes numeric more preferred than float8. Thus, for example, select '12.34'::numeric + 12.34; which draws a can't-resolve-operator error in 7.2, is resolved as numeric addition with these changes. Is this a good thing, or not? We could preserve the can't-resolve behavior by marking numeric-float8 as an allowed implicit coercion, but that seems ugly. I'm not sure we can do a whole lot better without some more wide-ranging revisions of the way we handle untyped numeric literals (as in past proposals to invent an UNKNOWNNUMERIC pseudo-type). Also, does anyone have any other nits to pick with this classification of which coercions are implicitly okay? I've started with a fairly tough approach of disallowing most implicit coercions, but perhaps this goes too far. regards, tom lane Coercions allowed implicitly: oid | result|input|prosrc --+-+-+--- 860 | bpchar | char| char_bpchar 408 | bpchar | name| name_bpchar 861 | char| bpchar | bpchar_char 944 | char| text| text_char 312 | float4 | float8 | dtof 236 | float4 | int2| i2tof 318 | float4 | int4| i4tof 311 | float8 | float4 | ftod 235 | float8 | int2| i2tod 316 | float8 | int4| i4tod 482 | float8 | int8| i8tod 314 | int2| int4| i4toi2 714 | int2| int8| int82 313 | int4| int2| i2toi4 480 | int4| int8| int84 754 | int8| int2| int28 481 | int8| int4| int48 1177 | interval| reltime | reltime_interval 1370 | interval| time| time_interval 409 | name| bpchar | bpchar_name 407 | name| text| text_name 1400 | name| varchar | text_name 1742 | numeric | float4 | float4_numeric 1743 | numeric | float8 | float8_numeric 1782 | numeric | int2| int2_numeric 1740 | numeric | int4| int4_numeric 1781 | numeric | int8| int8_numeric 946 | text| char| char_text 406 | text| name| name_text 2046 | time| timetz | timetz_time 2023 | timestamp | abstime | abstime_timestamp 2024 | timestamp | date| date_timestamp 2027 | timestamp | timestamptz | timestamptz_timestamp 1173 | timestamptz | abstime | abstime_timestamptz 1174 | timestamptz | date| date_timestamptz 2028 | timestamptz | timestamp | timestamp_timestamptz 2047 | timetz | time| time_timetz 1401 | varchar | name| name_text (38 rows) Coercions that will require explicit CAST, ::type, or typename(x) syntax (NB: in 7.2 all of these would have been allowed implicitly): oid | result|input|prosrc --+-+-+-- 2030 | abstime | timestamp |
Re: [HACKERS] Implicit coercions need to be reined in
Barry Lind [EMAIL PROTECTED] writes: My feeling is that this change as currently scoped will break a lot of existing apps. Especially the case where people are using where clauses of the form: bigintcolumn = '999' to get a query to use the index on a column of type bigint. Eh? That case will not change behavior in the slightest, because there's no type conversion --- the literal is interpreted as the target type to start with. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] help with bison
Neil, Will this allow you to pass bytea data as binary data in the parameters section (ability to bind values to parameters) or will this still require that the data be passed as a text string that the parser needs to parse. When passing bytea data that is on the order of Megs in size (thus the insert/update statement is multiple Megs in size) it takes a lot of CPU cycles for the parser to chug through sql statements that long. (In fact a posting to the jdbc mail list in the last couple of days shows that postgres is 22 times slower than oracle when handling a 1Meg value in a bytea column). thanks, --Barry Neil Conway wrote: On Thu, 11 Apr 2002 10:54:14 +0800 Christopher Kings-Lynne [EMAIL PROTECTED] wrote: Out of interest, since the FE/BE protocol apprently doesn't support prepared statements (bound variables), what does this patch actually _do_? It implements preparable statements, by adding 3 new SQL statements: PREPARE plan AS query; EXECUTE plan USING parameters; DEALLOCATE plan; I didn't write the original patch -- that was done by Karel Zak. But since that was several years ago, I'm working on cleaning it up, getting it to apply to current sources (which has taken a while), and fixing the remaining issues with it. Karel describes his work here: http://groups.google.com/groups?q=query+cache+planhl=enselm=8l4jua%242fo0%241%40FreeBSD.csie.NCTU.edu.twrnum=1 (If that's messed up due to newlines, search for query cache plan on Google Groups, it's the first result) Cheers, Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Implicit coercions need to be reined in
OK. My mistake. In looking at the regression failures in your post, I thought I saw errors being reported of this type. My bad. --Barry Tom Lane wrote: Barry Lind [EMAIL PROTECTED] writes: My feeling is that this change as currently scoped will break a lot of existing apps. Especially the case where people are using where clauses of the form: bigintcolumn = '999' to get a query to use the index on a column of type bigint. Eh? That case will not change behavior in the slightest, because there's no type conversion --- the literal is interpreted as the target type to start with. 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: [HACKERS] What's the CURRENT schema ?
Fernando Nasser wrote: Hiroshi Inoue wrote: Fernando Nasser wrote: As most things in the SQL standard, you have to collect information from several places and add it together. Look at 4.20, 11.1 and specially at the rules for schema qualified name. Then think a little bit about scenarios, trying to apply the rules. It is a pain, but there is no other way. I couldn't find the description CURRENT_SCHEMA == CURRENT_USER. If I recognize SQL99 correctly, the CURRENT schema is the schema defined in a SQL-client module not restricted to the CURRENT user. Yes, OK I wasn't wrong at this point. but we don't have a "module" language. You have to look for "session". Do you mean PostgreSQL by the *we* ? We have never been and would never be completely in conformity to standard. If we don't have a "module" language, does it mean we couldn't have any subsitute for SQL-client module ? regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] What's the CURRENT schema ?
Fernando Nasser wrote: As most things in the SQL standard, you have to collect information from several places and add it together. Look at 4.20, 11.1 and specially at the rules for schema qualified name. Then think a little bit about scenarios, trying to apply the rules. It is a pain, but there is no other way. I couldn't find the description CURRENT_SCHEMA == CURRENT_USER. If I recognize SQL99 correctly, the CURRENT schema is the schema defined in a SQL-client module not restricted to the CURRENT user. Well here's my proposal. 1) Use the different search path for table name and others. 2) Allow only one schema other than temp or catalog in the table name search path so that we can call it the CURRENT schema. Comments ? regards, Hiroshi Inoue ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] What's the CURRENT schema ?
Hiroshi Inoue wrote: Fernando Nasser wrote: As most things in the SQL standard, you have to collect information from several places and add it together. Look at 4.20, 11.1 and specially at the rules for schema qualified name. Then think a little bit about scenarios, trying to apply the rules. It is a pain, but there is no other way. I couldn't find the description CURRENT_SCHEMA == CURRENT_USER. If I recognize SQL99 correctly, the CURRENT schema is the schema defined in a SQL-client module not restricted to the CURRENT user. Yes, but we don't have a module language. You have to look for session. -- Fernando Nasser Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED] 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] A New Release list of places to contact about new releases of PostgreSQL
Hi everyone, I know we've already got a rough series of steps to follow when a new release comes out, but I feel it's worth putting out heads together and making a cheat sheet of which places to contact, and known good contacts there. Am thinking this after coming across the ZDNet download page for PostgreSQL. It's still got version 6.5.3 as being the one to download. Perhaps we should make a list of which places have downloads like this, and at release time a couple of people each take care of a few and confirm the changes? Sound feasible? :-) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] timeout implementation issues
Thomas Lockhart [EMAIL PROTECTED] writes: I do have a concern about how to implement some of the SET commands if we *do* respect transactional semantics. For example, SET TIME ZONE saves the current value of an environment variable (if available), and would need *at least* a before transaction and after transaction started pair of values. I intended for guc.c to manage this bookkeeping, thus freeing individual modules from worrying about it. That would require us to transpose the last few special-cased SET variables into generic GUC variables, but I consider that a Good Thing anyway. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RFC: Restructuring pg_aggregate
Hiroshi Inoue [EMAIL PROTECTED] writes: Tom Lane wrote: That means that a lot of low-level places *do* need to know about the dropped-column convention, else they can't make any sense of tuple layouts. Why ? As you already mentioned, there were not that many places to be changed. There are not many places to change if the implementation uses attisdropped, because we *only* have to hide the existence of the column at the parser level. The guts of the system don't know anything funny is going on; a dropped column looks the same as an undropped one throughout the executor. But with negative attnums, even such basic routines as heap_formtuple have to know about it, no? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] [Fwd: AW: More UB-Tree patent information]
Hi everyone, This is Prof. Bayer's response to the question is it alright to use UB-Tree's in Open Source projects?. It's a No, but we can discuss a licensing model type answer. Regards and best wishes, Justin Clift Original Message Subject: AW: More UB-Tree patent information Date: Wed, 10 Apr 2002 15:26:05 +0200 From: Prof. Rudolf Bayer [EMAIL PROTECTED] To: Justin Clift [EMAIL PROTECTED] Dear Justin, I am personally holder of the patents. concerning your question: Specifically wondering if it's alright to use UB-Tree's in Open Source projects. the answer is NO, unless there is a patent agreement with me. Please let me know, what specifically the interests and business models are, then we could discuss a licensing model in line with the already existing license agreements, best regards, R. Bayer * Prof. Rudolf Bayer, Ph.D. Institut fuer Informatik, Technische Universitaet Muenchen Orleansstr. 34, D-81667 Muenchen, Germany tel: ++49-89-48095 171 email: [EMAIL PROTECTED] fax: ++49-89-48095 170 http://www3.informatik.tu-muenchen.de -Ursprungliche Nachricht- Von: Justin Clift [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 9. April 2002 23:04 An: Professor Rudolf Bayer Cc: PostgreSQL General Mailing List Betreff: More UB-Tree patent information Hi Prof. Bayer, Haven't heard anything back from you regarding the patents on UB-Tree's. Specifically wondering if it's alright to use UB-Tree's in Open Source projects. On a related topic, in your paper The Universal B-Tree for multidimensional Indexing (http://mistral.in.tum.de/results/publications/TUM-I9637.pdf) you mention a German Patent Pending number of 196 35 429.3, is this the one which was approved in Europe? In the paper Bulk Loading a Data Warehouse built upon a UB-Tree (http://mistral.in.tum.de/results/publications/FKM+00.pdf) it mentions the Japanese Patent filed on 22nd May 2000, Application Number 2000-149648. Is this the Japanese patent for UB-Trees which hasn't yet been approved? :) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(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: [HACKERS] [Fwd: AW: More UB-Tree patent information]
On Wed, 2002-04-10 at 16:32, Justin Clift wrote: Hi everyone, This is Prof. Bayer's response to the question is it alright to use UB-Tree's in Open Source projects?. Have you found out _what_ exaclty is patented ? Is it just his concrete implementation of UB-Tree or something broader, like using one multi-dimensional index instead of multiple one-dimensional ones ? - Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [Fwd: AW: More UB-Tree patent information]
Hannu Krosing wrote: On Wed, 2002-04-10 at 16:32, Justin Clift wrote: Hi everyone, This is Prof. Bayer's response to the question is it alright to use UB-Tree's in Open Source projects?. Have you found out _what_ exaclty is patented ? Is it just his concrete implementation of UB-Tree or something broader, like using one multi-dimensional index instead of multiple one-dimensional ones ? Is there any way of finding out instead of asking him directly? Maybe the patent places have online info? Professor Bayer isn't being overly informative. Anyone know? :-) Regards and best wishes, Justin Clift - Hannu -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] A New Release list of places to contact about new releases
Justin Clift wrote: Hi everyone, I know we've already got a rough series of steps to follow when a new release comes out, but I feel it's worth putting out heads together and making a cheat sheet of which places to contact, and known good contacts there. Am thinking this after coming across the ZDNet download page for PostgreSQL. It's still got version 6.5.3 as being the one to download. Perhaps we should make a list of which places have downloads like this, and at release time a couple of people each take care of a few and confirm the changes? Sound feasible? Sure, throw it into a file in src/tools. We already have a RELEASE_CHANGES file there. -- 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 ---(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: [HACKERS] Implicit coercions need to be reined in
Awhile back I suggested adding a boolean column to pg_proc to control which type coercion functions could be invoked implicitly, and which would need an explicit cast: http://archives.postgresql.org/pgsql-hackers/2001-11/msg00803.php There is a relevant bug report #484 showing the dangers of too many implicit coercion paths: http://archives.postgresql.org/pgsql-bugs/2001-10/msg00108.php I have added such a column as part of the pg_proc changes I'm currently doing to migrate aggregates into pg_proc. So it's now time to debate the nitty-gritty: exactly which coercion functions should not be implicitly invokable anymore? My first-cut attempt at this is shown by the two printouts below. The first cut does not allow any implicit coercions to text from types that are not in the text category, which seems a necessary rule to me --- the above-cited bug report shows why free coercions to text are dangerous. However, it turns out that several of the regression tests fail with this rule; see the regression diffs below. Should I consider these regression tests wrong, and correct them? If not, how can we limit implicit coercions to text enough to avoid the problems illustrated by bug #484? Another interesting point is that I allowed implicit coercions from float8 to numeric; this is necessary to avoid breaking cases like insert into foo(numeric_col) values(12.34); since the constant will be initially typed as float8. However, because I didn't allow the reverse coercion implicitly, this makes numeric more preferred than float8. Thus, for example, select '12.34'::numeric + 12.34; which draws a can't-resolve-operator error in 7.2, is resolved as numeric addition with these changes. Is this a good thing, or not? We could preserve the can't-resolve behavior by marking numeric-float8 as an allowed implicit coercion, but that seems ugly. I'm not sure we can do a whole lot better without some more wide-ranging revisions of the way we handle untyped numeric literals (as in past proposals to invent an UNKNOWNNUMERIC pseudo-type). Also, does anyone have any other nits to pick with this classification of which coercions are implicitly okay? I've started with a fairly tough approach of disallowing most implicit coercions, but perhaps this goes too far. regards, tom lane Coercions allowed implicitly: oid | result|input|prosrc --+-+-+--- 860 | bpchar | char| char_bpchar 408 | bpchar | name| name_bpchar 861 | char| bpchar | bpchar_char 944 | char| text| text_char 312 | float4 | float8 | dtof 236 | float4 | int2| i2tof 318 | float4 | int4| i4tof 311 | float8 | float4 | ftod 235 | float8 | int2| i2tod 316 | float8 | int4| i4tod 482 | float8 | int8| i8tod 314 | int2| int4| i4toi2 714 | int2| int8| int82 313 | int4| int2| i2toi4 480 | int4| int8| int84 754 | int8| int2| int28 481 | int8| int4| int48 1177 | interval| reltime | reltime_interval 1370 | interval| time| time_interval 409 | name| bpchar | bpchar_name 407 | name| text| text_name 1400 | name| varchar | text_name 1742 | numeric | float4 | float4_numeric 1743 | numeric | float8 | float8_numeric 1782 | numeric | int2| int2_numeric 1740 | numeric | int4| int4_numeric 1781 | numeric | int8| int8_numeric 946 | text| char| char_text 406 | text| name| name_text 2046 | time| timetz | timetz_time 2023 | timestamp | abstime | abstime_timestamp 2024 | timestamp | date| date_timestamp 2027 | timestamp | timestamptz | timestamptz_timestamp 1173 | timestamptz | abstime | abstime_timestamptz 1174 | timestamptz | date| date_timestamptz 2028 | timestamptz | timestamp | timestamp_timestamptz 2047 | timetz | time| time_timetz 1401 | varchar | name| name_text (38 rows) Coercions that will require explicit CAST, ::type, or typename(x) syntax (NB: in 7.2 all of these would have been allowed implicitly): oid | result|input|prosrc --+-+-+-- 2030 | abstime | timestamp | timestamp_abstime 1180 | abstime | timestamptz | timestamptz_abstime 1480 | box | circle | circle_box 1446 | box | polygon | poly_box 1714 | cidr| text| text_cidr 1479 | circle | box | box_circle 1474 | circle | polygon | poly_circle 1179 | date| abstime | abstime_date 748 | date| text
