Re: [HACKERS] I am done
On Wed, 4 Sep 2002, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
Does anyone else have an opinion on this? If not, I will implement it per
Bruce's commentary.
On Mon, 2 Sep 2002, Bruce Momjian wrote:
I think the second, passing an arg to say whether it is server or
client, will do the trick, though now you need an error one too. I
guess you have to use #define and set it, or pass a string down with the
GUC variable and test that with strcmp.
I think you're going to end up un-merging the routines. There is no way
to pass an extra parameter to the set/check routines (at least not
There is a wrapper around the generic function:
const char *
assign_min_error_statement(const char *newval, bool doit, bool
interactive)
{
return(assign_msglvl(log_min_error_statement,newval,doit,interactive));
}
I would simply define some macros:
#define MSGLVL_MIN_ERR_STMT (10)
#define MSGLVL_MIN_CLI_MSGS (11)
#define MSGLVL_MIN_SVR_MSGS (12)
And assign_msglvl(), having been passed the variable 'caller', determined
by the calling function, will do something like this:
/* everyone has likes debug */
if (strcasecmp(newval, debug) == 0
caller (MSGLVL_MIN_ERR_STMT | MSGLVL_MIN_CLI_MSGS | MSGLVL_MIN_SVR_MSGS))
{ if (doit) (*var) = DEBUG1; }
/* ... */
else if (strcasecmp(newval, fatal) == 0
caller (MSGLVL_MIN_ERR_STMT | MSGLVL_MIN_SVR_MSGS))
{ if (doit) (*var) = FATAL; }
else if (strcasecmp(newval, off) == 0
caller MSGLVL_MIN_ERR_STMT)
{ if (doit) (*var) = MIN_ERR_STMT_OFF; }
Personally, I've never liked coding like this. The reason I merged the
base code for each function was so that the GUC code didn't get uglier as
more minimum-level-of-logging parameters were added. But with the code
above, the bitwise operations and appearance of the
assign_msglvl() routine will suffer the same fate, I'm afraid.
Since the flawed code is now in beta, it will need to be fixed. Do people
like the above solution or should I just revert to having a seperate
function for each GUC variable affected?
Gavin
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Please rename split(text,text,int) to splitpart
It seems that my last mail on this did not get through to the list ;( Please consider renaming the new builtin function split(text,text,int) to something else, perhaps split_part(text,text,int) (like date_part) The reason for this request is that 3 most popular scripting languages (perl, python, php) all have also a function with similar signature, but returning an array instead of single element and the (optional) third argument is limit (maximum number of splits to perform) I think that it would be good to have similar function in (some future release of) postgres, but if we now let in a function with same name and arguments but returning a single string instead an array of them, then we will need to invent a new and not so easy to recognise name for the real split function. Hannu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] contrib/tsearch
Hi Oleg/Teodor, I'm sorry to keep posting bugs without patches, but I'm just hoping you guys know the answer faster than I...I know you're busy. What does tsearch have against the word 'herring' (as in the fish). Why is it considered a stopword? Attached is example queries... Chris usa=# select food_id, brand,description,ftiidx from food_foods where description ilike '%herring%'; food_id | brand | description | ftiidx -++--+- 66245 | Kosher/Deli Foods | Herring, Smoked | 'food' 'smoke' 'kosher/deli' 66246 | Kosher/Deli Foods | Herring, in Sour Cream | 'food' 'sour' 'cream' 'kosher/deli' 4590 | - Generic -| Fish oil, herring| 'oil' 'fish' 'gener' 70737 | - Average All Brands - | Finfish, herring, Pacific, raw | 'raw' 'brand' 'pacif' 'averag' 'finfish' 70738 | - Average All Brands - | Finfish, herring, Pacific, cooked, dry heat | 'dri' 'cook' 'heat' 'brand' 'pacif' 'averag' 'finfish' 70739 | - Average All Brands - | Finfish, herring, Atlantic, raw | 'raw' 'brand' 'atlant' 'averag' 'finfish' 70740 | - Average All Brands - | Finfish, herring, Atlantic, pickled | 'brand' 'pickl' 'atlant' 'averag' 'finfish' 70741 | - Average All Brands - | Finfish, herring, Atlantic, kippered | 'brand' 'atlant' 'averag' 'kipper' 'finfish' 70742 | - Average All Brands - | Finfish, herring, Atlantic, cooked, dry heat | 'dri' 'cook' 'heat' 'brand' 'atlant' 'averag' 'finfish' 66026 | German | Herring, Pickled: Rollmops | 'pickl' 'german' 'rollmop' 66027 | German | Herring, Pickled: w/Sour Cream | 'cream' 'pickl' 'german' 'w/sour' (11 rows) usa=# select food_id, brand,description,ftiidx from food_foods where ftiidx ## 'herring'; NOTICE: Query contains only stopword(s) or doesn't contain lexem(s), ignored food_id | brand | description | ftiidx -+---+-+ (0 rows) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] contrib/tsearch
Hmmm...thinking about it, maybe 'herring' is being reduced to 'her' after the stemming process and hence is thought to be a stopword? This is a bug, but how should it be fixed? Although, tests don't support that: usa=# select food_id, brand,description,ftiidx from food_foods where ftiidx ## 'himring'; food_id | brand | description | ftiidx -+---+-+ (0 rows) usa=# select food_id, brand,description,ftiidx from food_foods where ftiidx ## 'hisring'; food_id | brand | description | ftiidx -+---+-+ (0 rows) usa=# select food_id, brand,description,ftiidx from food_foods where ftiidx ## 'hising'; food_id | brand | description | ftiidx -+---+-+ (0 rows) usa=# select food_id, brand,description,ftiidx from food_foods where ftiidx ## 'himing'; food_id | brand | description | ftiidx -+---+-+ (0 rows) All work...? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher Kings-Lynne Sent: Thursday, 5 September 2002 2:36 PM To: Hackers Subject: [HACKERS] contrib/tsearch Hi Oleg/Teodor, I'm sorry to keep posting bugs without patches, but I'm just hoping you guys know the answer faster than I...I know you're busy. What does tsearch have against the word 'herring' (as in the fish). Why is it considered a stopword? Attached is example queries... Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Inheritance
On Thu, 2002-09-05 at 03:57, Curt Sampson wrote: On Tue, 3 Sep 2002, Bruce Momjian wrote: Yep, this is where we are stuck; having an index span multiple tables in some way. Or implementing it by keeping all data in the table in which it was declared. (I.e., supertable holds all rows; subtable holds only the primary key and those columns of the row that are not in the supertable.) How would you do it for _multiple_ inheritance ? When implementing it on top of standard relational model you have more or less two ways to slice the problem 1) the way you describe (parent holding common columns + child tables for added child columns), which makes it easy to define constraints but hard to do inserts/updates/deletes on inherited tables 2) the postgresql way (a new table for each child), which makes it hard to define constraints but easy to do inserts/updates/deletes. From looking at the various discussions of this in books, and what it appears to me that the SQL standard says, it seems that their overall vision of table inheritance is to be consistent with the implementation that I described above. Yes. The SQL99 standard specifies only _single_ inheritance for tables + LIKE in column definition part, making the model somewhat similar to Java's (single inheritance + interfaces). This way it could probably be done even more effectively than you describe by: 1) keeping _all_ (not only the inherited columns) the data for inheritance hierarchy in the same physical file. 2) having partial indexes (involving tableoid=thiskindoftable) for possible speeding up of SELECT .. ONLY queries. 3) no changes to (unique) indexes - they still reference simple TID's without additional table part. 4) update/delete of all child tables are trivial as they are actually done in the same table and not using joins It seems that single inheritance avoids other conceptual problems, like what to do with primary keys when inheriting from two tables that have them. Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Inheritance
On 5 Sep 2002, Hannu Krosing wrote: On Thu, 2002-09-05 at 03:57, Curt Sampson wrote: Or implementing it by keeping all data in the table in which it was declared. (I.e., supertable holds all rows; subtable holds only the primary key and those columns of the row that are not in the supertable.) How would you do it for _multiple_ inheritance ? Exactly the same way. Each column resides in only one physical table, so you need only find the table it resides in, and do the insert there. I'll be happy to provide an example if this is not clear. 1) the way you describe (parent holding common columns + child tables for added child columns), which makes it easy to define constraints but hard to do inserts/updates/deletes on inherited tables I wouldn't say it makes it hard to do inserts, updates and deletes. Postgres already has pretty near all of the code it needs to support these updates, because these are the semantic equivalant of the separate actions applied to the separate tables within one transaction. 2) the postgresql way (a new table for each child), which makes it hard to define constraints but easy to do inserts/updates/deletes. I agree that making constraints work in this model is very difficult and a lot of work. This way it could probably be done even more effectively than you describe by: 1) keeping _all_ (not only the inherited columns) the data for inheritance hierarchy in the same physical file. You appear to have delved into a different database layer than one I'm looking at, here. I was examining storage on the table level, which is unrelated to files. (E.g., postgres sometimes stores a table in one file, sometimes in more than one. MS SQL Server stores many tables in one file. It doesn't matter which approach is used when discussing the two inheritance implementation options above.) 4) update/delete of all child tables are trivial as they are actually done in the same table and not using joins Or are you talking about storing all of the columns in a single table? That's a possibility, but wouldn't it be costly to update the entire table every time you add a new child table? And table scans on child tables would certainly be more costly if you had many of them, becuase the effective row width would be much wider. But it might be worth thinking about. It seems that single inheritance avoids other conceptual problems, like what to do with primary keys when inheriting from two tables that have them. I don't see where there's a conceptual problem here, either. With multiple inheritance you can simply demote both keys to candidate keys, and continue on as normal. (The only difference between a primary key and a candidate key is that you can leave out the column names when declaring foreign keys in another table.) cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Inheritance
On Thu, 2002-09-05 at 09:28, Curt Sampson wrote: On 5 Sep 2002, Hannu Krosing wrote: On Thu, 2002-09-05 at 03:57, Curt Sampson wrote: Or implementing it by keeping all data in the table in which it was declared. (I.e., supertable holds all rows; subtable holds only the primary key and those columns of the row that are not in the supertable.) How would you do it for _multiple_ inheritance ? Exactly the same way. Each column resides in only one physical table, so you need only find the table it resides in, and do the insert there. I'll be happy to provide an example if this is not clear. 1) the way you describe (parent holding common columns + child tables for added child columns), which makes it easy to define constraints but hard to do inserts/updates/deletes on inherited tables I wouldn't say it makes it hard to do inserts, updates and deletes. Postgres already has pretty near all of the code it needs to support these updates, because these are the semantic equivalant of the separate actions applied to the separate tables within one transaction. What I meant was that it is relatively more costly to update several physical tables than updating one . 2) the postgresql way (a new table for each child), which makes it hard to define constraints but easy to do inserts/updates/deletes. I agree that making constraints work in this model is very difficult and a lot of work. But again this is not _conceptually_ hard, just hard to implement efficiently. This way it could probably be done even more effectively than you describe by: 1) keeping _all_ (not only the inherited columns) the data for inheritance hierarchy in the same physical file. You appear to have delved into a different database layer than one I'm looking at, here. probably. I was describing to a way to efficiently implement single inheritance. The layer was somewhere between physical files and logical tables, i.e. above splitting stuff into main/toast and also above splitting big files to 1Gb chunks, but below logical tables, which are (or are not when omitting ONLY ;) still separate logically. Perhaps it could be named logical file. I was examining storage on the table level, which is unrelated to files. (E.g., postgres sometimes stores a table in one file, sometimes in more than one. MS SQL Server stores many tables in one file. It doesn't matter which approach is used when discussing the two inheritance implementation options above.) It does not matter in case you are assuming that the storage model can't be changed. The trick with inherited tables is that in some sense they are the same table and in another sense they are separate tables. 4) update/delete of all child tables are trivial as they are actually done in the same table and not using joins Or are you talking about storing all of the columns in a single table? That's a possibility, but wouldn't it be costly to update the entire table every time you add a new child table? You should not need it, as the storage for existing tuples does not change - even now you can do ADD COLUMN without touching existing tuples. And table scans on child tables would certainly be more costly if you had many of them, becuase the effective row width would be much wider. It would not be noticably wider (only 1 bit/column) even if I did propose storing all columns. What I was actually trying to describe was that the tuple format would be what it is currently, just stored in the same table with parent. But it might be worth thinking about. It seems that single inheritance avoids other conceptual problems, like what to do with primary keys when inheriting from two tables that have them. I don't see where there's a conceptual problem here, either. With multiple inheritance you can simply demote both keys to candidate keys, and continue on as normal. (The only difference between a primary key and a candidate key is that you can leave out the column names when declaring foreign keys in another table.) That's one possibility. The other would be to keep the one from the first table as primary and demote onlly the other primary keys. With single inheritance you don't even have to think about it. - Hannu ---(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] 7.3 gotchas for applications and client libraries
Was this going to make it into the release notes or something? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Lane Sent: Tuesday, 3 September 2002 9:54 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [HACKERS] 7.3 gotchas for applications and client libraries Bruce suggested that we need a porting guide to help people look for application and client-library code that will be broken by the changes in PG 7.3. Here is a first cut at documenting the issues. Comments welcome --- in particular, what have I missed? regards, tom lane Revising client-side code for PG 7.3 system catalogs Here are some notes about things to look out for in updating client-side code for PG 7.3. Almost anything that looks at the system catalogs is probably going to need work, if you want it to behave reasonably when you start using 7.3's new features such as schemas and DROP COLUMN. As an example, consider the task of listing the names and datatypes for a table named foo. In the past you may have done this with a query like SELECT a.attname, format_type(a.atttypid, a.atttypmod) FROM pg_class c, pg_attribute a WHERE c.relname = 'foo' AND a.attnum 0 AND a.attrelid = c.oid ORDER BY a.attnum ... ---(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] Inheritance
On 5 Sep 2002, Hannu Krosing wrote: What I meant was that it is relatively more costly to update several physical tables than updating one . Oh, I see. Not that this is that big a deal, I think. Given that it doesn't work correctly at the moment, making it work fast is a definite second priority, I would think. Once it's working right, one can always replace the internals with something else that does the same job but is more efficient. I agree that making constraints work in this model is very difficult and a lot of work. But again this is not _conceptually_ hard, just hard to implement efficiently. No, it's conceptually hard. Not all constraints are implemented with just a unique index you know. And changing a constraint means you have to check all the child tables, etc. etc. It's difficult just to track down down all the things you have to try to preserve. Not to mention, there's always the question of what happens to triggers and suchlike when handed a tuple with extra columns from what it expects, and having it modify the insert into a different table. The beauty of storing all supertable columns in the supertable itself is that the behaviour is automatically correct. What I was actually trying to describe was that the tuple format would be what it is currently, just stored in the same table with parent. So what you're saying is that each tuple in the table would have a format appropriate for its subtype, and the table would be full of tuples of varying types? At first blush, that seems like a reasonable approach, if it can be done. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Inheritance
I have a question about inheritance: You have 2 tables: Programmer and employee. Programmer inherits employee. You put in a generic employee record for someone, but then she becomes a programmer. What do you do? (I borrowed this example from a book by C.J. Date, who posed this question). Do you DELETE then INSERT? Something seems wrong with that somehow. Are the postgres developers agreed upon how that situation should be handled? What about the database users, and their expectations of the behavior? I am not advocating that we remove inheritence (I say this because this topic has generated some significant discussion about that). However, I will stick to the well-defined relational model until I see something useful from the inheritance system that is as well-defined. I agree it saves a few keystrokes (and can help organize things for you, as do objects in a programming language), but mind is more at peace when I am actually sure of what's happening. I can always throw more rules/views/triggers at the situation until I have a nice set of things to work with in the application. Or, I suppose, if someone shows me something that I can't do in the relational model, but can with inheritance, I might be convinced otherwise. Regards, Jeff Davis On Thursday 05 September 2002 01:05 am, Hannu Krosing wrote: On Thu, 2002-09-05 at 03:57, Curt Sampson wrote: On Tue, 3 Sep 2002, Bruce Momjian wrote: Yep, this is where we are stuck; having an index span multiple tables in some way. Or implementing it by keeping all data in the table in which it was declared. (I.e., supertable holds all rows; subtable holds only the primary key and those columns of the row that are not in the supertable.) How would you do it for _multiple_ inheritance ? When implementing it on top of standard relational model you have more or less two ways to slice the problem 1) the way you describe (parent holding common columns + child tables for added child columns), which makes it easy to define constraints but hard to do inserts/updates/deletes on inherited tables 2) the postgresql way (a new table for each child), which makes it hard to define constraints but easy to do inserts/updates/deletes. From looking at the various discussions of this in books, and what it appears to me that the SQL standard says, it seems that their overall vision of table inheritance is to be consistent with the implementation that I described above. Yes. The SQL99 standard specifies only _single_ inheritance for tables + LIKE in column definition part, making the model somewhat similar to Java's (single inheritance + interfaces). This way it could probably be done even more effectively than you describe by: 1) keeping _all_ (not only the inherited columns) the data for inheritance hierarchy in the same physical file. 2) having partial indexes (involving tableoid=thiskindoftable) for possible speeding up of SELECT .. ONLY queries. 3) no changes to (unique) indexes - they still reference simple TID's without additional table part. 4) update/delete of all child tables are trivial as they are actually done in the same table and not using joins It seems that single inheritance avoids other conceptual problems, like what to do with primary keys when inheriting from two tables that have them. Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Inheritance
On Thu, 5 Sep 2002, Jeff Davis wrote: You have 2 tables: Programmer and employee. Programmer inherits employee. You put in a generic employee record for someone, but then she becomes a programmer. What do you do? (I borrowed this example from a book by C.J. Date, who posed this question). Do you DELETE then INSERT? Something seems wrong with that somehow. This is not so wrong. If you think about it, you have the same problem in most object-oriented programming languages: a person object can't generally easily become a subclass of itself after being created. This is a case, I would say, where you simply don't want to use inheritance. A person has-a job, not is-a job. What about the database users, and their expectations of the behavior? Nobody really knows; table inheritance in databases is not well-defined. (Though perhaps the latest SQL spec. changes that.) However, I will stick to the well-defined relational model until I see something useful from the inheritance system that is as well-defined. Amen! :-) Or, I suppose, if someone shows me something that I can't do in the relational model, but can with inheritance, I might be convinced otherwise. I think that most people are at this point agreed that table inheritance, at least as currently implemented in any known system, doesn't offer anything that can't easily be done relationally. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Inheritance
On Thu, 2002-09-05 at 10:52, Curt Sampson wrote: On 5 Sep 2002, Hannu Krosing wrote: What I meant was that it is relatively more costly to update several physical tables than updating one . Oh, I see. Not that this is that big a deal, I think. Given that it doesn't work correctly at the moment, making it work fast is a definite second priority, I would think. But choosing an implementation that _can_be_ made to work fast is not. Once it's working right, one can always replace the internals with something else that does the same job but is more efficient. I still think that choosing the right implementation can also help in making it work right. I agree that making constraints work in this model is very difficult and a lot of work. But again this is not _conceptually_ hard, just hard to implement efficiently. No, it's conceptually hard. Not all constraints are implemented with just a unique index you know. And changing a constraint means you have to check all the child tables, etc. etc. It's difficult just to track down down all the things you have to try to preserve. It may be a lot of work, but not _conceptually_ hard. Conceptually you have to do the same thing as for a single table, but just for all inherited tables. Not to mention, there's always the question of what happens to triggers and suchlike when handed a tuple with extra columns from what it expects, and having it modify the insert into a different table. IMHO that the trigger should not be aware of underlying implementation - so it needs not worry about modifying the insert into a different table. The beauty of storing all supertable columns in the supertable itself is that the behaviour is automatically correct. But automatically correct may not be what you want ;) What about trigger that generates a cached printname using function printname(row) that is different for each table - here you definitely do not want to run the function defined for base table for anything inherited. What I was actually trying to describe was that the tuple format would be what it is currently, just stored in the same table with parent. So what you're saying is that each tuple in the table would have a format appropriate for its subtype, and the table would be full of tuples of varying types? At first blush, that seems like a reasonable approach, if it can be done. At least it makes some parts easier ;) Hannu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Inheritance
On 5 Sep 2002, Hannu Krosing wrote: Oh, I see. Not that this is that big a deal, I think. Given that it doesn't work correctly at the moment, making it work fast is a definite second priority, I would think. But choosing an implementation that _can_be_ made to work fast is not. I would say it definitely is. A correctly working implementation can be replaced. An incorrectly working implementation destroys data integrety. Which is more important for PostgreSQL? Speed or maintaining data integrity? Not to mention, there's always the question of what happens to triggers and suchlike when handed a tuple with extra columns from what it expects, and having it modify the insert into a different table. IMHO that the trigger should not be aware of underlying implementation - so it needs not worry about modifying the insert into a different table. I agree. The beauty of storing all supertable columns in the supertable itself is that the behaviour is automatically correct. But automatically correct may not be what you want ;) What about trigger that generates a cached printname using function printname(row) that is different for each table - here you definitely do not want to run the function defined for base table for anything inherited. Right. But that will be automatically correct when you store all base data in the base table. It's when you start storing those data in other tables that the trigger can get confused. Or are you saying that when I insert a row into just a child table, the trigger shouldn't be invoked on the parent table portion of that insert? If so, I'd strongly disagree. If that trigger is acting as an integrety constraint on the base table, you might destroy the table's integrity. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib/tsearch
On Thu, 5 Sep 2002, Christopher Kings-Lynne wrote: Hmmm...thinking about it, maybe 'herring' is being reduced to 'her' after the stemming process and hence is thought to be a stopword? This is a bug, but how should it be fixed? It's difficult question how to use stop words. We'll see what we could do. Probably, porter's stemming algorithm has problem here. 'herring' - 'her'~'ring' (I have a demo of english-russian stemmr, so you can play) http://intra.astronet.ru/db/lingua/snowball/ I'll ask Martin Porter if there could be an error stemmer. But I think the problem is in concept of using stop words. Should we check for stop words before stemming or after ? In the first case we have to collect all forms of stop-words which is doable but difficult to maintain, in latter - we'll have current problem. It's time for beta1 and I'm not sure if we could work on this issue right now, but I feel a big pressure from tsearch users :-) If people want to help us why not to work on stop words list including all forms ? In any case, we are not native english, so don't expect we'll create more or less decent list. Programming changes are trivial, probably we'll end for the moment just using compile time option. As always, your patches are welcome ! btw, you may test your queries much easier: list=# select 'herring'::mquery_txt; ERROR: Your query contained only stopword(s), ignored list=# select 'herring'::query_txt; query_txt --- 'herring' (1 row) Although, tests don't support that: usa=# select food_id, brand,description,ftiidx from food_foods where ftiidx ## 'himring'; food_id | brand | description | ftiidx -+---+-+ (0 rows) usa=# select food_id, brand,description,ftiidx from food_foods where ftiidx ## 'hisring'; food_id | brand | description | ftiidx -+---+-+ (0 rows) usa=# select food_id, brand,description,ftiidx from food_foods where ftiidx ## 'hising'; food_id | brand | description | ftiidx -+---+-+ (0 rows) usa=# select food_id, brand,description,ftiidx from food_foods where ftiidx ## 'himing'; food_id | brand | description | ftiidx -+---+-+ (0 rows) All work...? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher Kings-Lynne Sent: Thursday, 5 September 2002 2:36 PM To: Hackers Subject: [HACKERS] contrib/tsearch Hi Oleg/Teodor, I'm sorry to keep posting bugs without patches, but I'm just hoping you guys know the answer faster than I...I know you're busy. What does tsearch have against the word 'herring' (as in the fish). Why is it considered a stopword? Attached is example queries... Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] beta1 packaged
On Wed, 4 Sep 2002, Marc G. Fournier wrote: %ls -lt ~ftp/pub/source/v7.3beta Is this where you're putting it this time? Last time was ~ftp/pub/beta. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com == ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Inheritance
This is not so wrong. If you think about it, you have the same problem in most object-oriented programming languages: a person object can't generally easily become a subclass of itself after being created. This is a case, I would say, where you simply don't want to use inheritance. A person has-a job, not is-a job. But a person is-a employee (allow me to momentarily step aside from the rules of english grammer, if you would), and a person is-a programmer. That's why I didn't call my table job :) [1] I don't like the way some OO programming languages handle objects, if they mean to say you can't change an object's type without performing a logical data copy to a new object. If you don't use some kind of extra layer of abstraction in C, you will end up with that problem: you'd need to copy all that RAM over to change from one struct to another. Most people would rather take that RAM copying hit than all the hits for allowing room to expand (at least in some applications). However, postgres needs to provide that room to expand for each tuple anyway, so to go through the same copying seems bad (especially since we're no longer just talking RAM). Take as an example python... it's easy to emulate other objects: just assign to the attribute, even if it's not there yet, it'll add the attribute. Same with python, it's providing room to expand for it's objects already, so why do all the copying? Now compare with Java, and see why you'd be annoyed. It has the facilities to change the objects all around, but you can't do it. Even if you disregard all implementation details, and assume that the database is intelligent enough to not redundantly write data (and if you could name one such database, I would like to know), you're still doing something that doesn't logically make sense: you're deleting and inserting atomically, when the more obvious logical path is to expand on the data you already carry about an entity. I like entities to be mutable, at least as far as makes sense to an application. Try telling an employee that as part of a promotion, they're going to be fired, lose their workstation, then be re-hired, and get a new workstation; I bet he'd have an interesting expression on his face (hey, at least postgres guarantees the A in ACID, or else bad things could happen to that poor guy :) Thanks for responding, and I agreed with everything else you said. As you might have guessed, I don't much like most object-oriented languages if that's what they're going to try to tell me I have to do. Python works nicely, however :) Regards, Jeff Davis [1] Come to think of it, the JOIN operator seems to, at least on a first thought, represent the has-a relationship you describe. You could have the tuples manager and programmer in the table job and join with a people table. Don't ask about inheritance yet for this model, I'm still thinking about that one (does has-a even have an analogue to inheriteance?). Send me your thoughts about this, if you should have any. ---(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] Map of developers
On Thu, 5 Sep 2002, Christopher Kings-Lynne wrote: Anyone else think we should add some more pins to the developer map? At the moment, it looks like we have very few developers! If so then now's the time to do it 'cuze I'm planning on generating a new one as soon as I get this tcl tool working. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com == ---(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] Map of developers
On Thu, 5 Sep 2002, Bruce Momjian wrote: I will work on that this month. It is part of the advocacy project. Since when? --- Christopher Kings-Lynne wrote: Anyone else think we should add some more pins to the developer map? At the moment, it looks like we have very few developers! Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com == ---(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 Beta 1 Build Error on Cygwin
I get the following error when building beta 1 on CYGWIN_NT-5.1 PC9 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown: make[3]: Entering directory `/usr/local/src/postgresql-7.3b1/src/backend/utils/mb/conversion_procs/c yrillic_and_mic' gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../../../src/include -I/usr/local/include -DBUILDING_DLL=1 -c -o cyrillic_and_mic.o cyrillic_and_mic.c dlltool --export-all --output-def cyrillic_and_mic.def cyrillic_and_mic.o dllwrap -o cyrillic_and_mic.dll --dllname cyrillic_and_mic.dll --def cyrillic_and_mic.def cyrillic_and_mic.o ../../../../../../src/utils/dllinit.o -lcygipc -lcrypt -L/usr/local/lib -L../../../../../../src/backend -lpostgres Warning: resolving _CurrentMemoryContext by linking to __imp__CurrentMemoryContext (auto-import) fu01.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname' fu02.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname' fu03.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname' fu04.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname' fu05.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname' fu06.o(.idata$3+0xc): more undefined references to `libpostgres_a_iname' follow nmth00.o(.idata$4+0x0): undefined reference to `_nm__CurrentMemoryContext' collect2: ld returned 1 exit status dllwrap: gcc exited with status 1 make[3]: *** [cyrillic_and_mic.dll] Error 1 make[3]: Leaving directory `/usr/local/src/postgresql-7.3b1/src/backend/utils/mb /conversion_procs/cyrillic_and_mic' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/src/postgresql-7.3b1/src/backend/utils/mb /conversion_procs' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/local/src/postgresql-7.3b1/src' make: *** [all] Error 2 PC9 $ Regards, Dave ---(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] beta1 packaged
On Thu, 5 Sep 2002, Vince Vielhaber wrote: On Wed, 4 Sep 2002, Marc G. Fournier wrote: %ls -lt ~ftp/pub/source/v7.3beta Is this where you're putting it this time? Last time was ~ftp/pub/beta. actually, should be a symlink, but until I know the packaging and all is well, I'm avoiding put it in there ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] beta1 packaged
On Thu, 5 Sep 2002, Marc G. Fournier wrote: On Thu, 5 Sep 2002, Vince Vielhaber wrote: On Wed, 4 Sep 2002, Marc G. Fournier wrote: %ls -lt ~ftp/pub/source/v7.3beta Is this where you're putting it this time? Last time was ~ftp/pub/beta. actually, should be a symlink, but until I know the packaging and all is well, I'm avoiding put it in there ... Ok, I'll leave the script as is then. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com == ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Inheritance
On Thu, 2002-09-05 at 11:34, Curt Sampson wrote: On 5 Sep 2002, Hannu Krosing wrote: Oh, I see. Not that this is that big a deal, I think. Given that it doesn't work correctly at the moment, making it work fast is a definite second priority, I would think. But choosing an implementation that _can_be_ made to work fast is not. I would say it definitely is. A correctly working implementation can be replaced. An incorrectly working implementation destroys data integrety. Which is more important for PostgreSQL? Speed or maintaining data integrity? Both of course. The lack of one often makes the other unusable. But as MySQL experience suggest, often people select speed over data integrity. OTOH sometimes you happily accept a 10sec delay in updates to have data integrity (like when doing a money transfer over internet;) Not to mention, there's always the question of what happens to triggers and suchlike when handed a tuple with extra columns from what it expects, and having it modify the insert into a different table. IMHO that the trigger should not be aware of underlying implementation - so it needs not worry about modifying the insert into a different table. I agree. The beauty of storing all supertable columns in the supertable itself is that the behaviour is automatically correct. But automatically correct may not be what you want ;) What about trigger that generates a cached printname using function printname(row) that is different for each table - here you definitely do not want to run the function defined for base table for anything inherited. Right. But that will be automatically correct when you store all base data in the base table. It's when you start storing those data in other tables that the trigger can get confused. Or are you saying that when I insert a row into just a child table, the trigger shouldn't be invoked on the parent table portion of that insert? If so, I'd strongly disagree. Conceptually there are no portions of table - the trigger is invoked on one _tuple_ exactly (pg has only row-level triggers), and each tuple belongs to only one table regardless how it is implemented internally. If that trigger is acting as an integrety constraint on the base table, you might destroy the table's integrity. What I try to say is that you should have the same freedom with triggers that you have with select/insert/update/delete - you must be able to choose if the trigger is on the parent table ONLY or on parent and all children. And you should be able to override a trigger for child table even if it is defined on parent as applying to all children - I guess that overriding by trigger _name_ would be what most people expect. Suppose you have a table CITIZEN with table-level constraint IS_GOOD which is defined as kills_not_others(CITIZEN). and there is table CIVIL_SERVANT (..) UNDER CITIZEN. Now you have just one table MILITARY (...) UNDER CIVIL_SERVANT, where you have other criteria for IS_GOOD so you must either be able to override the trigger for that table (and its children) or make sure that the functions used are dynamically mached to the actual tuple type (header in Relational Model parlance) so that kills_not_others(MILITARY) will be used, which presents the system MILITARYs view of the being good ;) What I'm after here is dynamic (and automatic) row level dispach of the right function based on row type - so that for rows in CITIZEN or CIVIL_SERVANT the function kills_not_others(CITIZEN) will be used but for rows in MILITAY the kills_not_others(MILITARY) is used. - Hannu ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Inheritance
On Thu, 2002-09-05 at 12:29, Jeff Davis wrote:
This is not so wrong. If you think about it, you have the same
problem in most object-oriented programming languages: a person
object can't generally easily become a subclass of itself after
being created.
This is a case, I would say, where you simply don't want to use
inheritance. A person has-a job, not is-a job.
But a person is-a employee (allow me to momentarily step aside from the rules
of english grammer, if you would), and a person is-a programmer. That's why I
didn't call my table job :) [1]
I don't like the way some OO programming languages handle objects, if they
mean to say you can't change an object's type without performing a logical
data copy to a new object. If you don't use some kind of extra layer of
abstraction in C, you will end up with that problem: you'd need to copy all
that RAM over to change from one struct to another. Most people would rather
take that RAM copying hit than all the hits for allowing room to expand (at
least in some applications). However, postgres needs to provide that room to
expand for each tuple anyway, so to go through the same copying seems bad
(especially since we're no longer just talking RAM).
I would like to have UPDATEs both up and down the inheritance hierarchy,
so that when I have hierarchy
OBJECT(id serial primary key)
+ HUMAN(name text,age int)
+ EMPLOYEE(salary numeric)
+ ENGINEER(workstation computer)
+ PHB(laptop computer)
and ENGINEER named Bob
I could do
UPDATE ENGINEER
TO PHB
SET salary = salary * 2 + age * 1000,
laptop.disksize = max(laptop.disksize ,
workstation.disksize + 100)
WHERE name='Bob'
;
to promote Bob from an engineer to phb, give him a salary rise and a
laptop with default configuration ensuring big enough disk to keep all
his old files, but still keep all FK related records.
Take as an example python... it's easy to emulate other objects: just assign
to the attribute, even if it's not there yet, it'll add the attribute. Same
with python, it's providing room to expand for it's objects already, so why
do all the copying?
that's unless you use the new-style objects and __slots__
class myobj(object):
... __slots__ = ['a','b']
...
M = myobj()
M.a =1
M.c =1
Traceback (most recent call last):
File stdin, line 1, in ?
AttributeError: 'myobj' object has no attribute 'c'
Same with python, it's providing room to expand for it's objects already,
so why do all the copying?
[1] Come to think of it, the JOIN operator seems to, at least on a first
thought, represent the has-a relationship you describe. You could have the
tuples manager and programmer in the table job and join with a people
table. Don't ask about inheritance yet for this model, I'm still thinking
about that one (does has-a even have an analogue to inheriteance?).
Not in inheritance, but in OO world attributes are used to express has-a
relations. So
bob = people(name='Bob')
bob.job = job('Manager')
makes an has-a relation between Bob and his job in python
BTW, good programming guidelines in python tell you not to test if bob
is-a something but rather test if the interface for something exists -
to see if you can iterate over bob you do not test if bob is a sequence
but just try it:
try:
for idea in bob:
examine(idea)
except TypeError:
print 'Failed to iterate over %s %s !' % (bob,job.name, bob.name)
---
Hannu
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] locking of referenced table during constraint
Scott Shattuck [EMAIL PROTECTED] writes: ...why don't they allow the selects to read through adding a constraint? Hmm. We could probably allow that --- at least for some forms of ALTER TABLE, a ShareRowExclusive lock ought to be good enough. (That would allow SELECT and SELECT FOR UPDATE to run in parallel, but not any actual data changes.) Offhand I think this would be okay for trigger changes, since SELECT and SELECT FOR UPDATE are unaffected by triggers. I'm less sure that it's safe for any other kind of ALTER. It becomes time critical when the table has 3 million user account entries and the lock blocks people from having their login name verified, causing what's supposed to be a 24x7 e-commerce site to essentially go offline to users for 5 minutes or more just so you can add a constraint to a new table with no rows. Sorry, but that sucks. The only way ALTER TABLE ADD CONSTRAINT could take five minutes is if you are putting a new constraint on a large existing table. I don't really see how you can expect that to be a free operation --- the system has to look through all the existing rows to verify the constraint is met. Fooling with the schema of large production tables is not something you're going to do without downtime in *any* DB. 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] I am done
Gavin Sherry [EMAIL PROTECTED] writes: Since the flawed code is now in beta, it will need to be fixed. Do people like the above solution or should I just revert to having a seperate function for each GUC variable affected? I do not see a good reason why fatal and off shouldn't be allowed values for all three message variables. If we just did that, then you'd be back to sharable code. BTW, is it a good idea for server_min_messages and log_min_error_statement to be PGC_USERSET? I could see an argument that they should be PGC_SIGHUP, ie, settable only by the admin. As it is, any user can hide his activity from the logs. OTOH, in the past we've allowed anyone to change the debug level, and there haven't been complaints about it. There's some value in being able to kick the log level up a notch for a specific session, but knocking it down from the admin's default could be considered a bad thing. I suppose we could invent a PGC_SIGHUP min_server_min_messages variable that sets a minimum value below which the user can't set server_min_messages. Does that seem like a good idea, or overkill? A compromise position would be to make these two variables PG_SUSET, ie settable per-session but only if you're superuser. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] TODO item on triggers
Bruce Momjian [EMAIL PROTECTED] writes: Is this item completed? It sure looks like it: * Make triggers refer to columns by number, not name It is not necessary anymore. The triggers still use names, but there's code in ALTER...RENAME to fix the trigger parameters. I'm perfectly happy with that solution and see no need to do what the TODO item suggests. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.2 - 7.3 activity
Bruce Momjian [EMAIL PROTECTED] writes: Good question. As far as lines of *.[chy] code in pgsql/src, you have: Date | Release | Lines of code --+--+ ... 2002-02-04 | 7.2 | 394,274 2002-??-?? | 7.3 | 453,282 As you can see, a 15% increase over 7.2. And that's despite having removed a goodly amount of code to gborg. Do you have an idea how many lines of code were pushed out? You'd have to add them back to get truly comparable numbers. 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] beta1 packaged
Marc G. Fournier [EMAIL PROTECTED] writes: actually, should be a symlink, but until I know the packaging and all is well, I'm avoiding put it in there ... I pulled down the main tarball -- looks good AFAICT. 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] beta1 packaged
On Wed, 2002-09-04 at 22:39, Marc G. Fournier wrote: will announce it on -announce tomorrow, if ppl want to take a quick look at it ... man pages weren't included, but I did regenerate the docs per Peter's suggested commands ... './configure make check' passes on i386 FreeBSD. SunOS control.shared2 5.7 Generic_106541-20 sun4u sparc SUNW,Ultra-5_10 shows an error in ALTER TABLE tests: c cat src/test/regress/regression.diffs *** ./expected/alter_table.out Fri Aug 30 12:23:20 2002 --- ./results/alter_table.out Thu Sep 5 07:44:18 2002 *** *** 367,374 -- As should this ALTER TABLE FKTABLE ADD FOREIGN KEY(ftest1) references pktable(ptest1); NOTICE: ALTER TABLE will create implicit trigger(s) for FOREIGN KEY check(s) DROP TABLE pktable cascade; - NOTICE: Drop cascades to constraint $2 on table fktable NOTICE: Drop cascades to constraint $1 on table fktable DROP TABLE fktable; CREATE TEMP TABLE PKTABLE (ptest1 int, ptest2 inet, --- 367,374 -- As should this ALTER TABLE FKTABLE ADD FOREIGN KEY(ftest1) references pktable(ptest1); NOTICE: ALTER TABLE will create implicit trigger(s) for FOREIGN KEY check(s) + ERROR: Relation pg_temp_5. does not exist DROP TABLE pktable cascade; NOTICE: Drop cascades to constraint $1 on table fktable DROP TABLE fktable; CREATE TEMP TABLE PKTABLE (ptest1 int, ptest2 inet, == ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] beta1 packaged
Rod Taylor [EMAIL PROTECTED] writes: SunOS control.shared2 5.7 Generic_106541-20 sun4u sparc SUNW,Ultra-5_10 shows an error in ALTER TABLE tests: ALTER TABLE FKTABLE ADD FOREIGN KEY(ftest1) references pktable(ptest1); NOTICE: ALTER TABLE will create implicit trigger(s) for FOREIGN KEY check(s) + ERROR: Relation pg_temp_5. does not exist That's pretty bizarre. Is it reproducible? Can you get in there with a debugger and try to figure out what's going wrong? 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] Inheritance
I really like Hannu's idea of storing an entire (single-inheritance) hierarchy in a single file. I guess the question we need to ask ourselves is if we're prepared to abandon support of multiple inheritance. Personally I am, but... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.2 - 7.3 activity
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Good question. As far as lines of *.[chy] code in pgsql/src, you have: Date | Release | Lines of code --+--+ ... 2002-02-04 | 7.2 | 394,274 2002-??-?? | 7.3 | 453,282 As you can see, a 15% increase over 7.2. And that's despite having removed a goodly amount of code to gborg. Do you have an idea how many lines of code were pushed out? You'd have to add them back to get truly comparable numbers. Good point. I see 36k lines move to gborg, which makes the increase more like 25%. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Please rename split(text,text,int) to splitpart
Hannu Krosing wrote: It seems that my last mail on this did not get through to the list ;( Please consider renaming the new builtin function split(text,text,int) to something else, perhaps split_part(text,text,int) (like date_part) The reason for this request is that 3 most popular scripting languages (perl, python, php) all have also a function with similar signature, but returning an array instead of single element and the (optional) third argument is limit (maximum number of splits to perform) I think that it would be good to have similar function in (some future release of) postgres, but if we now let in a function with same name and arguments but returning a single string instead an array of them, then we will need to invent a new and not so easy to recognise name for the real split function. This is a good point, and I'm not opposed to changing the name, but it is too bad your original email didn't get through before beta1 was rolled. The change would now require an initdb, which I know we were trying to avoid once beta started (although we could change it without *requiring* an initdb I suppose). I guess if we do end up needing an initdb for other reasons, we should make this change too. Any other opinions? Is split_part an acceptable name? Also, if we add a todo to produce a real split function that returns an array, similar to those languages, I'll take it for 7.4. Thanks, Joe ---(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] I am done
Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: Since the flawed code is now in beta, it will need to be fixed. Do people like the above solution or should I just revert to having a seperate function for each GUC variable affected? I do not see a good reason why fatal and off shouldn't be allowed values for all three message variables. If we just did that, then you'd be back to sharable code. I recommended he only allow valid values for each variable. I think if we say we only support values X,Y,Z we had better throw an error if it anything else. BTW, is it a good idea for server_min_messages and log_min_error_statement to be PGC_USERSET? I could see an argument that they should be PGC_SIGHUP, ie, settable only by the admin. As it is, any user can hide his activity from the logs. OTOH, in the past we've allowed anyone to change the debug level, and there haven't been complaints about it. There's some value in being able to kick the log level up a notch for a specific session, but knocking it down from the admin's default could be considered a bad thing. I suppose we could invent a PGC_SIGHUP min_server_min_messages variable that sets a minimum value below which the user can't set server_min_messages. Does that seem like a good idea, or overkill? Seems a new GUC variable seems like overkill to me, and I think we need to allow it to be raised. I think we can make server_min_messages PGC_SUSET so only the admin can change it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] beta1 packaged
On Thu, 2002-09-05 at 11:19, Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: SunOS control.shared2 5.7 Generic_106541-20 sun4u sparc SUNW,Ultra-5_10 shows an error in ALTER TABLE tests: ALTER TABLE FKTABLE ADD FOREIGN KEY(ftest1) references pktable(ptest1); NOTICE: ALTER TABLE will create implicit trigger(s) for FOREIGN KEY check(s) + ERROR: Relation pg_temp_5. does not exist That's pretty bizarre. Is it reproducible? Can you get in there with a debugger and try to figure out what's going wrong? No, I've been unable to reproduce. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] possible vacuum improvement?
How about counting the number of dead tuples examined and the number of live tuples returned. As the ratio of dead tuples over live tuples visited increases the table becomes a candidate for vacuuming. -regards richt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Lane Sent: Tuesday, September 03, 2002 4:25 PM To: Mario Weilguni Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] possible vacuum improvement? Mario Weilguni [EMAIL PROTECTED] writes: That brings me to another point, can't the statistics collector used for that? Hmm, that would be a different way of attacking the problem. Not sure offhand which is better, but it'd surely be worth considering both. Note that collecting of dead-tuple counts requires input from aborted transactions as well as successful ones. I don't recall whether the stats collector currently collects anything from aborted xacts; that might or might not be a sticky point. 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Ok, I broke down...
In the process of upgrading a few systems for the Beta, I ended up writing a tool to upgrade the Foreign key, Unique, and Serial objects to their 7.3 version from the 7.2 version (may work on prior -- but not guarenteed). I imagine it'll fail miserably on mixed case, or names with spaces -- but oh well. Anyway, goes through step by step asking the user if they wish to upgrade each element. Lightly tested http://www.rbt.ca/postgresql/upgrade.shtml It assumes you've already dumped / upgraded / restored to 7.3 before running the script. Kinda slow, but safe to run more than once. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] I am done
Tom Lane wrote: There's some value in being able to kick the log level up a notch for a specific session, but knocking it down from the admin's default could be considered a bad thing. I suppose we could invent a PGC_SIGHUP min_server_min_messages variable that sets a minimum value below which the user can't set server_min_messages. Does that seem like a good idea, or overkill? A compromise position would be to make these two variables PG_SUSET, ie settable per-session but only if you're superuser. Oh, I just saw your compromise position. Yes, I think that is the way to go. In fact, aside from the security issue, allowing users to throw voluminous debug info into the server logs doesn't seem like a good idea anyway. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [CYGWIN] 7.3 Beta 1 Build Error on Cygwin
Dave, On Thu, Sep 05, 2002 at 12:54:50PM +0100, Dave Page wrote: I get the following error when building beta 1 on CYGWIN_NT-5.1 PC9 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown: make[3]: Entering directory `/usr/local/src/postgresql-7.3b1/src/backend/utils/mb/conversion_procs/cyrillic_and_mic' gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../../../src/include -I/usr/local/include -DBUILDING_DLL=1 -c -o cyrillic_and_mic.o cyrillic_and_mic.c [snip] dllwrap -o cyrillic_and_mic.dll --dllname cyrillic_and_mic.dll --def cyrillic_and_mic.def cyrillic_and_mic.o ../../../../../../src/utils/dllinit.o -lcygipc -lcrypt -L/usr/local/lib -L../../../../../../src/backend -lpostgres Warning: resolving _CurrentMemoryContext by linking to __imp__CurrentMemoryContext (auto-import) [snip] nmth00.o(.idata$4+0x0): undefined reference to `_nm__CurrentMemoryContext' I just submitted a patch to pgsql-patches to fix the above and to add a couple of missing DLLIMPORTs to src/include/miscadmin.h. FYI, plperl no longer builds cleanly against Cygwin Perl 5.6.1 because PostgreSQL no longer uses the Perl extension infrastructure. However, upgrading Cygwin Perl to 5.8.0 solves the problem because this version uses the conventional name for libperl.a instead of one that has the version embedded in it. Thanks again for the heads up. Jason ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] I am done
Bruce Momjian [EMAIL PROTECTED] writes: I do not see a good reason why fatal and off shouldn't be allowed values for all three message variables. If we just did that, then you'd be back to sharable code. I recommended he only allow valid values for each variable. I think if we say we only support values X,Y,Z we had better throw an error if it anything else. That's not what I said: I said allow all the values for each variable. And document it. Why shouldn't we let people turn off error logging if they want to? Seems a new GUC variable seems like overkill to me, and I think we need to allow it to be raised. I think we can make server_min_messages PGC_SUSET so only the admin can change it. Okay, and log_min_error_statement too. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [CYGWIN] 7.3 Beta 1 Build Error on Cygwin
-Original Message- From: Jason Tishler [mailto:[EMAIL PROTECTED]] Sent: 05 September 2002 16:30 To: Dave Page Cc: pgsql-hackers; pgsql-cygwin Subject: Re: [CYGWIN] 7.3 Beta 1 Build Error on Cygwin I just submitted a patch to pgsql-patches to fix the above and to add a couple of missing DLLIMPORTs to src/include/miscadmin.h. Yup, saw that, thanks. FYI, plperl no longer builds cleanly against Cygwin Perl 5.6.1 because PostgreSQL no longer uses the Perl extension infrastructure. However, upgrading Cygwin Perl to 5.8.0 solves the problem because this version uses the conventional name for libperl.a instead of one that has the version embedded in it. I'll bear that in mind, though I don't normally use Perl. Thanks again for the heads up. You're welcome, just trying to get a headstart on the testing of pgAdmin for 7.3 and the 7.3 regression testing... Jason ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] I am done
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I do not see a good reason why fatal and off shouldn't be allowed values for all three message variables. If we just did that, then you'd be back to sharable code. I recommended he only allow valid values for each variable. I think if we say we only support values X,Y,Z we had better throw an error if it anything else. That's not what I said: I said allow all the values for each variable. And document it. Why shouldn't we let people turn off error logging if they want to? But the client side doesn't make any sense to support FATAL. Am I missing something? Seems a new GUC variable seems like overkill to me, and I think we need to allow it to be raised. I think we can make server_min_messages PGC_SUSET so only the admin can change it. Okay, and log_min_error_statement too. Yes. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] I am done
Bruce Momjian [EMAIL PROTECTED] writes: But the client side doesn't make any sense to support FATAL. Am I missing something? Hm. I suppose a client setting above ERROR might break some application programs that expect either ERROR or a command-complete response ... but do we need to go out of our way to prohibit people from choosing settings that break their clients? If so, I've got a long list of things we'd better worry about ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] I am done
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: But the client side doesn't make any sense to support FATAL. Am I missing something? Hm. I suppose a client setting above ERROR might break some application programs that expect either ERROR or a command-complete response ... but do we need to go out of our way to prohibit people from choosing settings that break their clients? If so, I've got a long list of things we'd better worry about ... client_min_messages currently shows: #client_min_messages = notice # Values, in order of decreasing detail: # debug5, debug4, debug3, debug2, debug1, # log, info, notice, warning, error so it is only fatal and panic that are not allowed for clients. If you want to allow them, that is fine with me. It would make it more consistent, but of course I don't think a fatal or panic ever makes it to the client side. Your point that there should be a way of eliminating even ERROR coming to a client seems valid to me. Let's make the change. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] beta1 packaged
Guys, postgresql7.3b1 does not build :-(, seems like a missing multibyte directory ' | make[4]: Entering directory |`/home/masm/download/postgresql-7.3b1/src/backend/utils/time' | gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include | -c -o tqual.o tqual.c | /usr/bin/ld -r -o SUBSYS.o tqual.o | make[4]: Leaving directory |`/home/masm/download/postgresql-7.3b1/src/backend/utils/time' | make -C mb SUBSYS.o | make: Entering an unknown directory | make: *** mb: No such file or directory. Stop. | make: Leaving an unknown directory | make[3]: *** [mb-recursive] Error 2 | make[3]: Leaving directory `/home/masm/download/postgresql-7.3b1/src/backend/utils' | make[2]: *** [utils-recursive] Error 2 | make[2]: Leaving directory `/home/masm/download/postgresql-7.3b1/src/backend' | make[1]: *** [all] Error 2 | make[1]: Leaving directory `/home/masm/download/postgresql-7.3b1/src' | make: *** [all] Error 2 ` or I'm missing something? Regards, Manuel. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] I am done
Bruce Momjian [EMAIL PROTECTED] writes: of course I don't think a fatal or panic ever makes it to the client side. Of course it does. Try entering a bad password as a trivial example. We punt *after* we send the elog. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Map of developers
Vince Vielhaber wrote: On Thu, 5 Sep 2002, Bruce Momjian wrote: I will work on that this month. It is part of the advocacy project. Since when? Since I decide to take over the world. :-) What I meant was that it was on my TODO list as part of advocacy stuff I plan for September. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Map of developers
On Thu, 5 Sep 2002, Bruce Momjian wrote: Vince Vielhaber wrote: On Thu, 5 Sep 2002, Bruce Momjian wrote: I will work on that this month. It is part of the advocacy project. Since when? Since I decide to take over the world. :-) What I meant was that it was on my TODO list as part of advocacy stuff I plan for September. Rape and pillage is on your todo list? Go find your own content. The map is The PostgreSQL Developers not The PostgreSQL Advocacy Squad. The last thing we need is the two maps getting out of sync, and no, I don't plan on using yours. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com == ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib/tsearch
Oleg, The Porter stemming stems herring and herrings to her, which is a bit unfortunate. A quick fix is to put 'herring/herrings' in the exception list in the english (porter2) stemmer, but I'll look at this case over the next few days and see if I can come up with something a bit better. Interesting that no one has reported this before. Martin ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] TODO item on triggers
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Is this item completed? It sure looks like it: * Make triggers refer to columns by number, not name It is not necessary anymore. The triggers still use names, but there's code in ALTER...RENAME to fix the trigger parameters. I'm perfectly happy with that solution and see no need to do what the TODO item suggests. OK, item removed, again. ;-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] beta1 packaged
Manuel Sugawara [EMAIL PROTECTED] writes: or I'm missing something? So it would seem. The utils/mb directory is certainly there in the full tarball that I pulled from ftp.us.postgresql.org this morning. How did you acquire your source tree, exactly? 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] I am done
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: of course I don't think a fatal or panic ever makes it to the client side. Of course it does. Try entering a bad password as a trivial example. We punt *after* we send the elog. Oh, that's good. I guess it was PANIC I assumed never made it to the client. Well, anyway, client should support the same values as server. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] beta1 packaged
Tom Lane [EMAIL PROTECTED] writes: So it would seem. The utils/mb directory is certainly there in the full tarball that I pulled from ftp.us.postgresql.org this morning. How did you acquire your source tree, exactly? The file is postgresql-base-7.3b1.tar.gz from ftp://ftp.postgresql.org/pub/source/v7.3beta/ may be I need postgresql-7.3b1.tar.gz? Regards, Manuel. -- No es que no puedan hallar la solución: es que no ven el problema. G.K. Chesterson ---(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] beta1 packaged
On 5 Sep 2002, Manuel Sugawara wrote: Tom Lane [EMAIL PROTECTED] writes: So it would seem. The utils/mb directory is certainly there in the full tarball that I pulled from ftp.us.postgresql.org this morning. How did you acquire your source tree, exactly? The file is postgresql-base-7.3b1.tar.gz from ftp://ftp.postgresql.org/pub/source/v7.3beta/ may be I need postgresql-7.3b1.tar.gz? You need either the 7.3b1.tar.gz (which is everything), or you need to get all the various -*- parts (which are more manageable) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] beta1 packaged
Marc G. Fournier [EMAIL PROTECTED] writes: You need either the 7.3b1.tar.gz (which is everything), or you need to get all the various -*- parts (which are more manageable) Oh, well. Thanks Regards, Manuel. -- No es que no puedan hallar la solución: es que no ven el problema. G.K. Chesterson ---(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] Map of developers
On Thu, 5 Sep 2002, Bruce Momjian wrote: Vince Vielhaber wrote: On Thu, 5 Sep 2002, Bruce Momjian wrote: Vince Vielhaber wrote: On Thu, 5 Sep 2002, Bruce Momjian wrote: I will work on that this month. It is part of the advocacy project. Since when? Since I decide to take over the world. :-) What I meant was that it was on my TODO list as part of advocacy stuff I plan for September. Rape and pillage is on your todo list? Go find your own content. The map is The PostgreSQL Developers not The PostgreSQL Advocacy Squad. The last thing we need is the two maps getting out of sync, and no, I don't plan on using yours. OK, what I really meant is that I want to make changes to the list of developers on the developers page and have you regenerate the map once that is updated. It is related to advocacy. Maybe I can be just vague enough again to push your buttons. ;-) Push 'em all you want, just don't bitch about the result! Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com == ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Inheritance
On Thu, Sep 05, 2002 at 10:23:02AM -0400, Tom Lane wrote: I really like Hannu's idea of storing an entire (single-inheritance) hierarchy in a single file. Wouldn't this require solving the ALTER TABLE ADD COLUMN (to parent) column ordering problem? I guess the question we need to ask ourselves is if we're prepared to abandon support of multiple inheritance. Personally I am, but... No opinion - I've not used the inheritance much, since I'm not willing to give up referential integrity. Ross ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] test, please ignore
I'm suspecting that something blocks mail from my home computer This is sent to test if it is so. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Inheritance
On Thu, 2002-09-05 at 19:23, Tom Lane wrote: I really like Hannu's idea of storing an entire (single-inheritance) hierarchy in a single file. I guess the question we need to ask ourselves is if we're prepared to abandon support of multiple inheritance. Personally I am, but... So am I, but I think we should move in stages - 1) first implement the SQL99 standard CREATE TABLE mytable() UNDER parenttable ; using the above idea and make it work right vs constraints, triggers, functions, etc. This should include the ability to include other table structures using LIKE : CREATE TABLE engine(...); CREATE TABLE vehicule(...); CREATE TABLE car ( model text, wheels wheel[], LIKE engine, ) UNDER vehicule; which could then hopefully be used for migrating most code of form CREATE TABLE car ( model text primary key, wheels wheel[] ) INHERITS (vehicule, engine); it would be nice (maybe even neccessary) to keep the current functionality that columns introduced by LIKE are automatically added/renamed/deleted when LIKE's base table changes. 2) when it is working announce non-SQL99-standard-and-broken INHERITS to be deprecated and removed in future. 3) give people time for some releases to move over to UNDER + LIKE . Or if someone comes up with bright ideas/impementations for fixing multiple inheritance, then un-deprecate and keep it. 4) else try to remove INHERITS. 5) if too many people object, goto 3) ;) --- Hannu ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Libpq.dll Souce Code
Dear all, I want to make library for visual basic to connect to PostgreSQL, but I have problem to get libpq.dll source code. Can somebody help me ? (Sorry for bad english :)) Best Regards, Achmad Amin __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com ---(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] Inheritance
On Thu, 5 Sep 2002, Jeff Davis wrote: But a person is-a employee (allow me to momentarily step aside from the rules of english grammer, if you would), and a person is-a programmer. That's why I didn't call my table job :) [1] Certainly it's not the case that a person is-a job, by virtue of the fact that a person can have no job. Nor is it the case that a person is-a programmer; not all people are programmers. Perhaps you're reversing the sense of is-a? One says subtype is-a supertype, not supertype is-a subtype. But even reversing these, it's not the case that job is-a person, by virtue of the fact that you cannot use a job anywhere you can use a person. (A person can file his tax return, a job can't.) That might be a matter of bad mappings of object names to real-world concepts, though. As for programmer is-a person, yes, you could model things that way if you really wanted to. But it's a bad way to do it because, as you point out, a person can change his job, or not have a job. Now what do you do with that programmer-subtype-of-person object you created? I think in this case English misled you: we do say that he is a programmer, but what we really mean is that one of the characteristics of that person is that he programs. So create a separate characteristic type and have the person object have-a as many or as few of those characteristics as you need. I don't like the way some OO programming languages handle objects, if they mean to say you can't change an object's type without performing a logical data copy to a new object. That's not a problem with the programming language; that's you modelling things badly. Take as an example python... it's easy to emulate other objects: just assign to the attribute, even if it's not there yet, it'll add the attribute. Same with python, it's providing room to expand for it's objects already, so why do all the copying? Now compare with Java, and see why you'd be annoyed. It has the facilities to change the objects all around, but you can't do it. Yes, you can't do it in Java because you Can't Do It in a language where you can specify static typing. If I have field that holds a String, I'm given a guarantee that, if I can put a reference in that field, it is and always will be a String. In non-statically-typed languages that give you the option of changing types, you might give a referenc to a string, change the objects type on me, and then I might blow up when I try to use it later. These bugs tend to be quite difficult to track down because the source and manifestation of the problem can be widely separated in code and in time. That's why most languages don't allow this. ...when the more obvious logical path is to expand on the data you already carry about an entity. Yes, that's the perfectly obvious path. And that's just what the relational model lets us do, and do very well. Why do you want to use an ill-fitting, error-prone model when you've already got something that works better? [1] Come to think of it, the JOIN operator seems to, at least on a first thought, represent the has-a relationship you describe. You bet! Hey, this relational stuff doesn't suck so badly after all, does it? Especially for a 30-year old theory. :-) cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(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] contrib/tsearch
On Thu, 5 Sep 2002, Martin Porter wrote: Oleg, The Porter stemming stems herring and herrings to her, which is a bit unfortunate. A quick fix is to put 'herring/herrings' in the exception list in the english (porter2) stemmer, but I'll look at this case over the next few days and see if I can come up with something a bit better. Unfrtunately, we wrote tsearch module before the Snowball project has started, so we used one implementation we found in the net (www.muscat.com) and there is no exception list. OpenFTS uses snowball stemming, so we'd like to have a fix. I think we have enough arguments to use snowball stemmers in tsearch also. Interesting that no one has reported this before. :-) Thanks Cristopher for his persistence. Martin Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(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] beta1 packaged
Marc G. Fournier wrote: On 5 Sep 2002, Manuel Sugawara wrote: Tom Lane [EMAIL PROTECTED] writes: So it would seem. The utils/mb directory is certainly there in the full tarball that I pulled from ftp.us.postgresql.org this morning. How did you acquire your source tree, exactly? The file is postgresql-base-7.3b1.tar.gz from ftp://ftp.postgresql.org/pub/source/v7.3beta/ may be I need postgresql-7.3b1.tar.gz? You need either the 7.3b1.tar.gz (which is everything), or you need to get all the various -*- parts (which are more manageable) I am confused. Are you saying the base file isn't compilable? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.2 - 7.3 activity
On Thu, 2002-09-05 at 20:12, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Good question. As far as lines of *.[chy] code in pgsql/src, you have: Date | Release | Lines of code --+--+ ... 2002-02-04 | 7.2 | 394,274 2002-??-?? | 7.3 | 453,282 As you can see, a 15% increase over 7.2. And that's despite having removed a goodly amount of code to gborg. Do you have an idea how many lines of code were pushed out? You'd have to add them back to get truly comparable numbers. Good point. I see 36k lines move to gborg, which makes the increase more like 25%. Has anyone run any speed tests to see how 7.2 and 7.3 compare ? Hannu ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] beta1 packaged
Bruce Momjian [EMAIL PROTECTED] writes: You need either the 7.3b1.tar.gz (which is everything), or you need to get all the various -*- parts (which are more manageable) I am confused. Are you saying the base file isn't compilable? My idea was that it is. Regards, Manuel. ---(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] beta1 packaged
On Thu, 5 Sep 2002, Bruce Momjian wrote: Marc G. Fournier wrote: On 5 Sep 2002, Manuel Sugawara wrote: Tom Lane [EMAIL PROTECTED] writes: So it would seem. The utils/mb directory is certainly there in the full tarball that I pulled from ftp.us.postgresql.org this morning. How did you acquire your source tree, exactly? The file is postgresql-base-7.3b1.tar.gz from ftp://ftp.postgresql.org/pub/source/v7.3beta/ may be I need postgresql-7.3b1.tar.gz? You need either the 7.3b1.tar.gz (which is everything), or you need to get all the various -*- parts (which are more manageable) I am confused. Are you saying the base file isn't compilable? Hrmm ... that is odd, now that you mention it ... but the file 'distributions' between v7.2 and v7.3beta appear to be the same, so -base- was broken in the old one too? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] beta1 packaged
Bruce Momjian writes: I am confused. Are you saying the base file isn't compilable? The mb stuff is missing because it used to be optional in the old splitting scheme. Needs to be rethought. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] beta1 packaged
Marc G. Fournier writes: Scary, even with removing a load of stuff over to gborg, its still gotten bigger then the last release :) Not hard to find the culprit: 7.2: 3.4Msrc/backend/utils/mb 7.3: 9.6Msrc/backend/utils/mb -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.3 Beta 1 Build Error on Cygwin
Dave Page writes: I get the following error when building beta 1 on CYGWIN_NT-5.1 PC9 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown: Should all be fixed now. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] contrib Makefile
Joe Conway writes: I just tried to build all of contrib, and it stops at earthdistance. Whoops... -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] beta1 packaged
Marc G. Fournier [EMAIL PROTECTED] writes: Hrmm ... that is odd, now that you mention it ... but the file 'distributions' between v7.2 and v7.3beta appear to be the same, so -base- was broken in the old one too? It was never intended that the base tarfile was alone sufficient to do anything, was it? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.3 Beta 1 Build Error on Cygwin
Peter, On Thu, Sep 05, 2002 at 08:33:20PM +0200, Peter Eisentraut wrote: Dave Page writes: I get the following error when building beta 1 on CYGWIN_NT-5.1 PC9 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown: Should all be fixed now. Huh? I don't see any recent CVS commits to indicate this. Jason ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] beta1 packaged
Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: Hrmm ... that is odd, now that you mention it ... but the file 'distributions' between v7.2 and v7.3beta appear to be the same, so -base- was broken in the old one too? It was never intended that the base tarfile was alone sufficient to do anything, was it? OK, so if base isn't compilable, then what is it good for? I don't see any add-on packages that would make it usable. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 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] beta1 packaged
Peter Eisentraut wrote: Marc G. Fournier writes: Scary, even with removing a load of stuff over to gborg, its still gotten bigger then the last release :) Not hard to find the culprit: 7.2: 3.4Msrc/backend/utils/mb 7.3: 9.6Msrc/backend/utils/mb Wow. Just checking my CVS, the /mb stuff appears to be 17% of our source tree. Now that they are loadable, can we get enough of it in the base to make it compilable and leave the rest for the full tarball. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] postgres crowd may find this interesting ;)
Just in time for 7.3 beta 1 : http://dsc.discovery.com/news/briefs/20020902/elephant.html --- Hannu ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 7.3 Beta 1 Build Error on Cygwin
Peter, On Thu, Sep 05, 2002 at 02:51:31PM -0400, Bruce Momjian wrote: Jason Tishler wrote: On Thu, Sep 05, 2002 at 08:33:20PM +0200, Peter Eisentraut wrote: Should all be fixed now. Huh? I don't see any recent CVS commits to indicate this. I see as a commit: [snip] I assume it was in there. Sorry for the noise, but at the time: cvs status include/miscadmin.h makefiles/Makefile.win did *not* indicate any recent commits. Maybe you sent the above email before you committed your changes? Anyway, I just tried a: make distclean rm include/miscadmin.h makefiles/Makefile.win # remove my patch cvs update make and got the following error: [snip] make[3]: Leaving directory `/home/jt/src/pgsql/src/backend/utils' dlltool --dllname postgres.exe --output-exp postgres.exp --def postgres.def gcc -L/usr/local/lib -o postgres.exe -Wl,--base-file,postgres.base postgres.exp access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o libpq/SUBSYS.o(.text+0x1c84):crypt.c: undefined reference to `crypt' port/SUBSYS.o(.text+0x262):pg_sema.c: undefined reference to `semget' [snip] I can get postgres.exe to successfully link by manually appending -lcrypt -lcygipc to the end of the above gcc command line. Since you are already working on this, would you be willing to fix this problem? Thanks, Jason ---(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] beta1 packaged
Bruce Momjian [EMAIL PROTECTED] writes: OK, so if base isn't compilable, then what is it good for? I don't see any add-on packages that would make it usable. AFAIR, the only reason for having the split packaging is to accommodate people who are downloading across flaky connections --- less to retry if your connection drops. You still have to download all the data if you want to have a useful package, no? 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] PL/Perl?
On Wed, 2002-09-04 at 19:41, Larry Rosenman wrote: On Wed, 2002-09-04 at 17:54, Tom Lane wrote: Larry Rosenman [EMAIL PROTECTED] writes: I upgraded PostgreSQL to 7.2.1 from a 7.2beta (yeah, I know). One of my users requested plperl, so I got it to createlang, but it SIGSEGV's on any simple perl. I was seeing the same with perl 5.6.1 and PG 7.2.* on HPUX 10.20. However, I have just verified that perl 5.8.0 works okay with PG CVS tip (not much testing, but it handles a simple plperl function). Could you see whether 5.8.0 plays any nicer on your setup? Need to check with my user, I'll let ya know. Well, I tried to install 5.8.0 on my 8.0.1 (beta) system, and blew cc up with an internal compiler error. I'll have to wait for Caldera to fix that. Sorry. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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] beta1 packaged
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, so if base isn't compilable, then what is it good for? I don't see any add-on packages that would make it usable. AFAIR, the only reason for having the split packaging is to accommodate people who are downloading across flaky connections --- less to retry if your connection drops. You still have to download all the data if you want to have a useful package, no? That was not my understanding. If that was the issue, we would release packages numbered 1-5. Marc splits them up saying if you don't want the docs, don't download them. I assume opt is /contrib. My guess is he had the multibyte stuff out in /opt but now they are required. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Add check constraint bug
The following happens in latest CVS and a fresh database: create table test (a int); insert into test values (1); alter table test add column b text check (b ''); alter table test add check (a 0); alter table test add check (a 1); After the last command I get ERROR: CheckConstraintFetch: unexpected record found for rel test and then the table seems to be wedged because any access to it will get the same error. Also, psql seems to forget about check constraints in peculiar ways: create table test (a int); insert into test values (1); alter table test add column b text check (b ''); \d test alter table test add check (a 0); \d test The first shows: Table public.test Spalte | Typ | Attribute +-+--- a | integer | b | text| The second shows: Table public.test Spalte | Typ | Attribute +-+--- a | integer | b | text| Check-Constraints: »test_b« (b ''::text) »$1« (a 0) Note the first one doesn't show any constraints. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Multibyte support in oracle_compat.c
Tatsuo Ishii writes: BTW, nls has same problem as above, no? I guess nls depeneds on locale and it may conflict with the database-specific encoding and/or the automatic FE/BE encoding conversion. GNU gettext does its own encoding conversion. It reads the program's character encoding from the LC_CTYPE locale and converts the material in the translation catalogs on the fly for output. This is great in general, really, but for the postmaster it's a problem. If LC_CTYPE is fixed for the cluster and you later on change your mind about the message language the it will be recoded into the character set that LC_CTYPE says. And if that character set does not match the one that is set as the backend encoding internally then who knows what will happen when this stuff is recoded again as it's sent to the client. Big, big mess. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] Removal of PGPASSWORDFILE in beta
I have removed PGPASSWORDFILE in CVS and therefore in beta2. It was decided that $HOME/.pgpass should always be tested, rather than have an environment variable for it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] beta1 packaged
0On Thu, 5 Sep 2002, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, so if base isn't compilable, then what is it good for? I don't see any add-on packages that would make it usable. AFAIR, the only reason for having the split packaging is to accommodate people who are downloading across flaky connections --- less to retry if your connection drops. You still have to download all the data if you want to have a useful package, no? Correct ... even on high speed connections, I've had problems in the past getting large files to download, so it makes it easier if you only have to retry a part, instead of hte whole thing ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] beta1 packaged
Marc G. Fournier wrote: 0On Thu, 5 Sep 2002, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, so if base isn't compilable, then what is it good for? I don't see any add-on packages that would make it usable. AFAIR, the only reason for having the split packaging is to accommodate people who are downloading across flaky connections --- less to retry if your connection drops. You still have to download all the data if you want to have a useful package, no? Correct ... even on high speed connections, I've had problems in the past getting large files to download, so it makes it easier if you only have to retry a part, instead of hte whole thing ... Then why do we mark them with stuff. Isn't it easier to just label them 1-5? I can see the docs being split out, but I don't understand the other splits. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Inheritance
On Thu, 2002-09-05 at 08:15, Hannu Krosing wrote: On Thu, 2002-09-05 at 11:34, Curt Sampson wrote: On 5 Sep 2002, Hannu Krosing wrote: If that trigger is acting as an integrety constraint on the base table, you might destroy the table's integrity. What I try to say is that you should have the same freedom with triggers that you have with select/insert/update/delete - you must be able to choose if the trigger is on the parent table ONLY or on parent and all children. Sounds like a mechanism to make the distinction between virtual (child can override parent) and non-virtual (child is constrained by the parent) constraints are needed. After all, there are two basic needs for constraints. One is for relational integrity and the other is business rule integrity. That is, one seeks to ensure that the database makes sense in respect to the data model (a shoe is a product) while the other is to enforce business rules (products are never free). Seems like the DBA should be able to dictate which domain his constraint falls into in some manner. And you should be able to override a trigger for child table even if it is defined on parent as applying to all children - I guess that overriding by trigger _name_ would be what most people expect. That's the reason I used virtual and non-virtual above. If we think using C++ idioms, the child is stuck with it if it's deemed non-virtual. Generally speaking, if someone designed something with that expectation in mind, there's probably a good reason for it. In this case, we could assume that such non-virtual constraints would be to help ensure proper RI. Something that otherwise, IMO, would be tossed out with the bath water. What I'm after here is dynamic (and automatic) row level dispach of the right function based on row type - so that for rows in CITIZEN or CIVIL_SERVANT the function kills_not_others(CITIZEN) will be used but for rows in MILITAY the kills_not_others(MILITARY) is used. I think we're touching on some form of RTTI information here. That is, triggers and even functions may need to be able to dynamically determine the row type that is actively being worked on. If we're on the same page, I think that seemingly makes a lot of sense. What about the concept of columns being public or private? That is, certain columns may not be inherited by a child? Any thought to such a concept? Perhaps different types of table inheritance can be considered in our model...has-a, is-a, etc... Regards, Greg Copeland signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Add check constraint bug
On Thu, 5 Sep 2002, Peter Eisentraut wrote: The following happens in latest CVS and a fresh database: create table test (a int); insert into test values (1); alter table test add column b text check (b ''); alter table test add check (a 0); alter table test add check (a 1); After the last command I get ERROR: CheckConstraintFetch: unexpected record found for rel test and then the table seems to be wedged because any access to it will get the same error. I don't have reasonable access to the machine at home for code purposes, but it looks to me that the add column line is the one that's causing the bug. It's inserting a check constraint but not upping relchecks which seems to work because it's zero and therefore doesn't even look, but the add check is incrementing the count and inserting its constraint which makes 2 real constraints and relchecks=1 which causes the error. This is probably also why it forgets about the check constraint below since relchecks is 0, but I didn't look. Note that: create table test(a int check (a3)); alter table test add column b text check(b''); select * from test; will error. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Inheritance
On Fri, 2002-09-06 at 03:19, Greg Copeland wrote: On Thu, 2002-09-05 at 08:15, Hannu Krosing wrote: On Thu, 2002-09-05 at 11:34, Curt Sampson wrote: On 5 Sep 2002, Hannu Krosing wrote: If that trigger is acting as an integrety constraint on the base table, you might destroy the table's integrity. What I try to say is that you should have the same freedom with triggers that you have with select/insert/update/delete - you must be able to choose if the trigger is on the parent table ONLY or on parent and all children. Sounds like a mechanism to make the distinction between virtual (child can override parent) and non-virtual (child is constrained by the parent) constraints are needed. After all, there are two basic needs for constraints. One is for relational integrity and the other is business rule integrity. That is, one seeks to ensure that the database makes sense in respect to the data model (a shoe is a product) while the other is to enforce business rules (products are never free). Seems like the DBA should be able to dictate which domain his constraint falls into in some manner. And you should be able to override a trigger for child table even if it is defined on parent as applying to all children - I guess that overriding by trigger _name_ would be what most people expect. That's the reason I used virtual and non-virtual above. If we think using C++ idioms, the child is stuck with it if it's deemed non-virtual. Generally speaking, if someone designed something with that expectation in mind, there's probably a good reason for it. In this case, we could assume that such non-virtual constraints would be to help ensure proper RI. Something that otherwise, IMO, would be tossed out with the bath water. I agree to this. What I described (making overriding decision solely in child) is probably a bad idea. What I'm after here is dynamic (and automatic) row level dispach of the right function based on row type - so that for rows in CITIZEN or CIVIL_SERVANT the function kills_not_others(CITIZEN) will be used but for rows in MILITAY the kills_not_others(MILITARY) is used. I think we're touching on some form of RTTI information here. That is, triggers and even functions may need to be able to dynamically determine the row type that is actively being worked on. Should be easy if the row comes directly from a table : just use tableoid column. If we're on the same page, I think that seemingly makes a lot of sense. What about the concept of columns being public or private? That is, certain columns may not be inherited by a child? Any thought to such a concept? Perhaps different types of table inheritance can be considered in our model...has-a, is-a, etc... I can't fit this in my mental model of table inheritance for two reasons 1) all parent table columns must be present in child 2) granting some right to parent should automatically allow selecting from children both are required for select/insert/update/delete to work on table and its children (i.e. without ONLY) But maybe i just need to think more about it ;) -- Hannu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] beta1 packaged
On Fri, 2002-09-06 at 03:14, Marc G. Fournier wrote: 0On Thu, 5 Sep 2002, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, so if base isn't compilable, then what is it good for? I don't see any add-on packages that would make it usable. AFAIR, the only reason for having the split packaging is to accommodate people who are downloading across flaky connections --- less to retry if your connection drops. You still have to download all the data if you want to have a useful package, no? Correct ... even on high speed connections, I've had problems in the past getting large files to download, so it makes it easier if you only have to retry a part, instead of hte whole thing ... Most modern ftp servers and clients support resuming aborted downloads, no ? [hannu@rh72 DL]$ ncftp ftp://ftp.postgresql.org/pub/source/v7.3beta/ NcFTP 3.1.3 (Mar 27, 2002) by Mike Gleason ([EMAIL PROTECTED]). Connecting to 64.49.215.8... postgresql.org FTP server (lukemftpd 1.2 beta 1) ready. Logging in... Guest login ok, access restrictions apply. Logged in to ftp.postgresql.org. Current remote directory is /pub/source/v7.3beta. ncftp /pub/source/v7.3beta get postgresql-test-7.3b1.tar.gz postgresql-test-7.3b1.tar.gz: ETA: 0:03 0.63/ 1.02 MB 131.44 kB/s *** NB! I pressed ^C here select: Interrupted system call postgresql-test-7.3b1.tar.gz: 0.72/ 1.02 MB 112.17 kB/s get postgresql-test-7.3b1.tar.gz: data transfer aborted by local user. ncftp /pub/source/v7.3beta get postgresql-test-7.3b1.tar.gz The local file postgresql-test-7.3b1.tar.gz already exists. Local:753768 bytes, dated Thu Sep 05 07:28:40 GMT-5 2002. Remote: 1070154 bytes, dated Thu Sep 05 07:28:40 GMT-5 2002. [O]verwrite? [R]esume? [A]ppend to? [S]kip? [N]ew Name? [O!]verwrite all? [R!]esume all? [S!]kip all? [C]ancel R postgresql-test-7.3b1.tar.gz:1.02 MB 112.59 kB/s ncftp /pub/source/v7.3beta --- Hannu ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Add check constraint bug
On Thu, 5 Sep 2002, Stephan Szabo wrote: On Thu, 5 Sep 2002, Peter Eisentraut wrote: The following happens in latest CVS and a fresh database: create table test (a int); insert into test values (1); alter table test add column b text check (b ''); alter table test add check (a 0); alter table test add check (a 1); After the last command I get ERROR: CheckConstraintFetch: unexpected record found for rel test and then the table seems to be wedged because any access to it will get the same error. Just fyi, 7.2.1 does this too. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Add check constraint bug
Peter Eisentraut [EMAIL PROTECTED] writes: The following happens in latest CVS and a fresh database: create table test (a int); insert into test values (1); alter table test add column b text check (b ''); This bug's been there awhile I fear. The failure occurs when AlterTableAddColumn needs to add a check constraint AND the new column causes AlterTableCreateToastTable to do its thing. The reason there is a bug is that AlterTableCreateToastTable gratuitously does a heap_mark4update, thereby selecting the un-updated version of the pg_class tuple as its basis for modification (and ignoring the HeapTupleSelfUpdated return code that warned that there was a problem). I've said before that I do not like heap_mark4update in catalog manipulations, and here's a perfect example of why it's a bad idea. 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] I am done
On Thu, 5 Sep 2002, Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: Since the flawed code is now in beta, it will need to be fixed. Do people like the above solution or should I just revert to having a seperate function for each GUC variable affected? I do not see a good reason why fatal and off shouldn't be allowed values for all three message variables. If we just did that, then you'd be back to sharable code. This was one of my other suggestions: does it matter if people can set client_min_messages to, say, PANIC -- since they wont get it anyway. BTW, is it a good idea for server_min_messages and log_min_error_statement to be PGC_USERSET? I could see an argument that they should be PGC_SIGHUP, ie, settable only by the admin. As it is, any user can hide his activity from the logs. OTOH, in the past we've allowed anyone to change the debug level, and there haven't been complaints about it. There's some value in being able to kick the log level up a notch for a specific session, but knocking it down from the admin's default could be considered a bad thing. I suppose we could invent a PGC_SIGHUP min_server_min_messages variable that sets a minimum value below which the user can't set server_min_messages. Does that seem like a good idea, or overkill? I think it would be important to implement it this way. I'm surprised this hasn't come up before. Still, it'd be a 7.4 item. A compromise position would be to make these two variables PG_SUSET, ie settable per-session but only if you're superuser. Sounds like a reasonably compromise. I cannot think of a reason why people would be setting server_min_messages per session in production. Perhaps this should be changed for 7.3? regards, tom lane Gavin ---(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] Add check constraint bug
Is there a TODO here? --- Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: The following happens in latest CVS and a fresh database: create table test (a int); insert into test values (1); alter table test add column b text check (b ''); This bug's been there awhile I fear. The failure occurs when AlterTableAddColumn needs to add a check constraint AND the new column causes AlterTableCreateToastTable to do its thing. The reason there is a bug is that AlterTableCreateToastTable gratuitously does a heap_mark4update, thereby selecting the un-updated version of the pg_class tuple as its basis for modification (and ignoring the HeapTupleSelfUpdated return code that warned that there was a problem). I've said before that I do not like heap_mark4update in catalog manipulations, and here's a perfect example of why it's a bad idea. 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]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] I am done
Gavin Sherry wrote: On Thu, 5 Sep 2002, Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: Since the flawed code is now in beta, it will need to be fixed. Do people like the above solution or should I just revert to having a seperate function for each GUC variable affected? I do not see a good reason why fatal and off shouldn't be allowed values for all three message variables. If we just did that, then you'd be back to sharable code. This was one of my other suggestions: does it matter if people can set client_min_messages to, say, PANIC -- since they wont get it anyway. Seems it is OK and is equivalent to off. BTW, is it a good idea for server_min_messages and log_min_error_statement to be PGC_USERSET? I could see an argument that they should be PGC_SIGHUP, ie, settable only by the admin. As it is, any user can hide his activity from the logs. OTOH, in the past we've allowed anyone to change the debug level, and there haven't been complaints about it. There's some value in being able to kick the log level up a notch for a specific session, but knocking it down from the admin's default could be considered a bad thing. I suppose we could invent a PGC_SIGHUP min_server_min_messages variable that sets a minimum value below which the user can't set server_min_messages. Does that seem like a good idea, or overkill? I think it would be important to implement it this way. I'm surprised this hasn't come up before. Still, it'd be a 7.4 item. I think restricting it to super-user is better. A compromise position would be to make these two variables PG_SUSET, ie settable per-session but only if you're superuser. Sounds like a reasonably compromise. I cannot think of a reason why people would be setting server_min_messages per session in production. Perhaps this should be changed for 7.3? I can imagine doing it so you can log something and look at it later. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Multibyte support in oracle_compat.c
GNU gettext does its own encoding conversion. It reads the program's character encoding from the LC_CTYPE locale and converts the material in the translation catalogs on the fly for output. This is great in general, really, but for the postmaster it's a problem. If LC_CTYPE is fixed for the cluster and you later on change your mind about the message language the it will be recoded into the character set that LC_CTYPE says. And if that character set does not match the one that is set as the backend encoding internally then who knows what will happen when this stuff is recoded again as it's sent to the client. Big, big mess. Then in another word, it's completely broken. Sigh. -- Tatsuo Ishii ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Add check constraint bug
Bruce Momjian [EMAIL PROTECTED] writes: Is there a TODO here? I've committed a fix for the immediate problem. I want to take a very hard look at the other heap_mark4update calls, though. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.2 - 7.3 activity
Bruce Momjian [EMAIL PROTECTED] writes: Good question. As far as lines of *.[chy] code in pgsql/src, you have: Date | Release | Lines of code --+--+ ... 2002-02-04 | 7.2 | 394,274 2002-??-?? | 7.3 | 453,282 As you can see, a 15% increase over 7.2. And that's despite having removed a goodly amount of code to gborg. Do you have an idea how many lines of code were pushed out? You'd have to add them back to get truly comparable numbers. Probably a more accurate assessment would in fact be the number of _changes_ ie. the size of the diffs... But really hard to figure out of course! Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PL/Perl?
On Thu, 2002-09-05 at 15:16, Larry Rosenman wrote: On Wed, 2002-09-04 at 19:41, Larry Rosenman wrote: On Wed, 2002-09-04 at 17:54, Tom Lane wrote: Larry Rosenman [EMAIL PROTECTED] writes: I upgraded PostgreSQL to 7.2.1 from a 7.2beta (yeah, I know). One of my users requested plperl, so I got it to createlang, but it SIGSEGV's on any simple perl. I was seeing the same with perl 5.6.1 and PG 7.2.* on HPUX 10.20. However, I have just verified that perl 5.8.0 works okay with PG CVS tip (not much testing, but it handles a simple plperl function). Could you see whether 5.8.0 plays any nicer on your setup? Need to check with my user, I'll let ya know. Well, I tried to install 5.8.0 on my 8.0.1 (beta) system, and blew cc up with an internal compiler error. I'll have to wait for Caldera to fix that. Sorry. Well, this system has GCC as well, and GCC groked PERL 5.8.0, and, TA DA, PL/PERL works with 5.8.0... THanks all... -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Ok, I broke down...
Whoot! I was just thinking about writing such a tool. Thanks. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rod Taylor Sent: Friday, 6 September 2002 12:38 AM To: PostgreSQL-development Subject: [HACKERS] Ok, I broke down... In the process of upgrading a few systems for the Beta, I ended up writing a tool to upgrade the Foreign key, Unique, and Serial objects to their 7.3 version from the 7.2 version (may work on prior -- but not guarenteed). I imagine it'll fail miserably on mixed case, or names with spaces -- but oh well. Anyway, goes through step by step asking the user if they wish to upgrade each element. Lightly tested http://www.rbt.ca/postgresql/upgrade.shtml It assumes you've already dumped / upgraded / restored to 7.3 before running the script. Kinda slow, but safe to run more than once. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Contrib installcheck problems
OK, I note that the regression tests for the following contribs are failing: cube intarray seg Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] 7.3 beta announcement
I haven't see the beta announcement on the announce list. Do we announce it there? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 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
