| 1) Otto Hirr Re: [GENERAL] Sun acquires MySQL |
|
|
| The intent is to get out in the open their "official" statement. That in tu= rn may create a... |
|
|
|
|
|
|
|
> From: Geoffrey Gowey> Sounds reasonable, but what one manager answers today is subject to be> changed by another tomorrow.The intent is to get out in the open their "official" statement. That in tu= rn may create a discussion inside Sun that may not have taken place. If postgres community does not like the stand, then lobby to change it. Lik= e you say, nothing either in time or by individual is forever locked in. If the postgres community likes it, then be sure to continue to support Sun= so that they continue in that direction. If they come out with a favorable= strategy or had a planned strategy but kept it to themselves and postgres = disses them, then they may take their toys and decide to play in other ways. But get it out in the open as much as can be done. Simple. Then you know wh= ere they stand/don't-stand/or remain mute. Then you can take further action. Rumors/opinions are just that. Postgres needs to have an "official spokesman" make a request at a "very im= portant top official" that is responsible for the acquisition. ..Otto
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
|
|
|
| 2) Otto Hirr Re: [GENERAL] Sun acquires MySQL |
|
|
| So why not go directly to the "source", Sun itself, and ask them? Someone like Bruce should just... |
|
|
|
|
|
|
|
> Russ Brown wrote:> > http://blogs.mysql.com/kaj/sun-acquires-mysql.html/> >> > What does this mean for Sun's support of Postgres?> >So why not go directly to the "source", Sun itself, and ask them? Someone like Bruce should just knock on the door and ask. Then you can evaluate the answer. Either a lie, the truth, or somewhere in-between, and the answer may only have a certain "shelf-life", for what is true today in the tech industry is false later. ..Otto
|
|
|
| 3) Otto Hirr [Alzabo] methodmaker issue |
|
|
| Greetings, I have several tables with relationships between them. All tables are to have some... |
|
|
|
|
|
|
|
Greetings, I have several tables with relationships between them. All tables are to have some attributes such as created_by, created_on, modified_by, etc. If I turn on 'all' in MethodMaker, it will attempt to create lookup_columns between related tables, including items like those listed above. Only certain columns should be used as lookup_columns, but not others. Furthermore MethodMakers complains about (as example): MethodMaker: Creating lookup_columns method MyApp::Data::Row::event->modified_on \ will override the method of the same name in the parent class MethodMaker: skipping lookup_columns method MyApp::Data::Row::event->modified_on \ subroutine already exists. Question, I want to use 'all' for MethodMaker as a general rule, but then create exceptions... How can this be done, or am I missing something. Regards, ..Otto
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Alzabo-general mailing list
[email protected: Alzabo-ge...@lists.sourceforge.net]
https://lists.sourceforge.net/lists/listinfo/alzabo-general |
|
|
| 4) Otto Hirr [Alzabo] pre-query for insert??? |
|
|
| Greetings, I've turned on sql debug and simply insert a few records into a table. It seems that sql... |
|
|
|
|
|
|
|
Greetings, I've turned on sql debug and simply insert a few records into a table. It seems that sql is being generated to pre-query for uniqueness on unique fields... and I have referential_integrity =0. Is this right? Is there a pre-query being done? I have yet to step through the code... ..Otto
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Alzabo-general mailing list
[email protected: Alzabo-ge...@lists.sourceforge.net]
https://lists.sourceforge.net/lists/listinfo/alzabo-general |
|
|
| 5) Otto Hirr [Alzabo] unintended in mail list....? |
|
|
| in looking at some of the messages, i see at bottom something to the effect of "2 messages have... |
|
|
|
|
|
|
|
in looking at some of the messages, i see at bottom something to the effect of "2 messages have been excluded from this view by a project administrator" i had an idea for one of the problems someone presented but then was wondering if other peoples responses (but not readable) had already answered the issue...?
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Alzabo-general mailing list
[email protected: Alzabo-ge...@lists.sourceforge.net]
https://lists.sourceforge.net/lists/listinfo/alzabo-general |
|
|
| 6) Otto Hirr Re: [Alzabo] Can't locate object method "User_t" |
|
|
| Greetings David, I believe that it is because potential_row changed in the version of Alzabo when... |
|
|
|
|
|
|
|
Greetings David, I believe that it is because potential_row changed in the version of Alzabo when Apprentice was created and the current version of Alzabo. I am working through Apprentice now to learn mason/alzabo. I dropped out the Apprentice::Data::PotentialRow::User::is_logged_in and changed the Apprentice::Data::Row::User::is_logged_in to check is_potential and return that value. ..Otto
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Alzabo-general mailing list
[email protected: Alzabo-ge...@lists.sourceforge.net]
https://lists.sourceforge.net/lists/listinfo/alzabo-general |
|
|
| 7) Otto Hirr [Mason] Apprentice-0.2.tar.gz missing Build.PL? |
|
|
| The INSTALL states: |Start the installation with the following command: | perl Build.PL However... |
|
|
|
|
|
|
|
The INSTALL states: |Start the installation with the following command: | perl Build.PL However Build.PL does not exist. It is not in the MANIFEST. Yes, I have all the pre-reqs installed. What am I missing... either file(s) or a concept... Thanks, ..Otto ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV |
|
|
| 8) Otto Hirr Re: RFC: A brief guide to nulls |
|
|
| I think that having this topic defined and available will be of great benefit... !!! Thanks... |
|
|
|
|
|
|
|
I think that having this topic defined and available
will be of great benefit... !!! Thanks Richard.
Some additional thoughts based upon what other people
have explicitly or implicitly implied. Peter quoted the sql
definition as:
>Every data type includes a special value, called the null value,
and my earlier post implied that, but...
I believe that one needs to be VERY explicit in the
distinction between sementic meaning of some field
and the values accessable. Using the example proposed
in earlier posts, the storing of sex field for a customer.
The example query was:
> SELECT * FROM customer WHERE sex='M';
> SELECT * FROM customer WHERE sex<>'M';
One person suggested:
>For example sex could be classified as
> 'n' - not applicable
> 'f' - female
> 'm' - male
> null - yet unknown
>...
>if customers sex is unknown - null, we can't decide
>whether they're men or not.
Which is straying way into the semantic information of
the field. In reality we have:
+Fieldname(sex)------------------+
|..............|value|{somevalue}|
|..............|nullP|{1or0} |
+--------------------------------+
Every field has a value portion and a nullP portion.
Here I use nullP, which is either 1 or 0, indicating
that the field is NULL or NOTNULL.
NOTNULL means that the value field has a value.
NULL means that the value field does not have a value.
Period. Anything else begins to stray into the semantic
range. Using the above...
> 'n' - not applicable
> 'f' - female
> 'm' - male
> null - yet unknown
which we could code as..
.....................................meaning
+Fieldname(sex)------------------+
|..............|value|{n} | not applicable
|..............|nullP|{0} |
+--------------------------------+
+Fieldname(sex)------------------+
|..............|value|{f} | female
|..............|nullP|{0} |
+--------------------------------+
+Fieldname(sex)------------------+
|..............|value|{m} | male
|..............|nullP|{0} |
+--------------------------------+
+Fieldname(sex)------------------+
|..............|value|{} |
|..............|nullP|{1} | <no value>
+--------------------------------+
If I was a clerk, looking at a person and could not
tell their sex due to appearance, etc, that should
probably be coded: 'u'-unknown
The "concept" of null meaning unknown is SEMANTIC...
in the case of sex.
The nullP, ie testing via NULL/NOTNULL, means that
one can either test or (should/can) access the value field.
No other meaning should be implied. The application
on up the ladder implies the meaning behind not having
a value.
The point I'm trying to make here is that one should not
intermix the application meaning of having/not-having
a value with the value itself.
Especially since you can have a NOTNULL field that
has a text value having no bytes in it, i.e. a string
field that has no characters...
Humm... don't know if I made my point clear as mud...
Best regards,
.. Otto
|
|
|
| 9) Otto Hirr Re: A brief guide to nulls |
|
|
| Another viewpoint, is to go a bit further into implementation... i.e. for every field, there are... |
|
|
|
|
|
|
|
Another viewpoint, is to go a bit further into implementation... i.e. for every field, there are two items... *one item being the null/notnull info *other item being the value info of the field per the type at def time This faciliatates the concepts of where <fieldname> is null ... testing the null/notnull info where <fieldname> is not null ... testing the null/notnull info where <fieldname> = "somevalue" ... testing the value info etc. Trying to "hide" the concept that every field has TWO items, the value and whether it is null/notnull, seems to confuse people. By SIMPLY stating that every SQL field has two items, then causes a scripter to think a bit more deeply about a where clause... Hence making your example ... > SELECT * FROM customer WHERE sex='M';> SELECT * FROM customer WHERE sex<>'M';> Now you might think this returns all customers, but it will miss those> where sex is null. You've asked for all rows where the value of sex is 'M'> and all those with values not equal to 'M' but not rows with *no value atall* all that less mysterious... i.e. the above two selects only tested one of the two items for the SQL field, the other item to test is the null/notnull item. .. Otto
> -----Original Message-----
> From: [email protected: pgsql-sql-...@postgresql.org]
> [email protected: pgsql-sql-...@postgresql.org]On Behalf Of [email protected: d...@archonet.com]
> Sent: Wednesday, January 15, 2003 9:23 AM
> To: [email protected: pgsq...@postgresql.org]
> Subject: RFC: A brief guide to nulls
>
>
> There have been a few posts recently where people have had
> problems with
> nulls. Anyone got comments on the below before I submit it to
> techdocs?
>
> TIA
>
> - Richard Huxton
>
> A Brief Guide to NULLs
> ======================
>
> What is a null?
> ===============
> A null is *not* an empty string.
> A null is *not* a value.
> A null is *not* a "special" value.
> A null is the absence of a value.
>
>
> What do nulls mean?
> ===================
> Well, they *should* mean one of two things:
> 1. There is no applicable value
> 2. There is a value but it is unknown
>
> Example 1: Imagine you have a customer table with name and sex fields.
> If you get a new customer "ACME Widgets Ltd", the sex field
> is meaningless
> since your customer is a company (case 1).
> If you get a new customer "Jackie Smith" they might be male
> or female, but
> you might not know (case 2).
>
> Example 2: You have an address table with
> (street,city,county,postalcode)
> fields.
> You might insert an address ("10 Downing
> Street","London",Null,"WC1 1AA")
> since you don't have a valid county.
> You might also insert an address ("1 Any
> Street","Maidstone","Kent",Null)
> where there *must be* a valid postalcode, but you don't know
> what it is.
>
> It might be useful to be able to distinguish between these
> two cases - not
> applicable and unknown, but there is only one option "Null"
> available to
> us, so we can't.
>
>
> How do nulls work?
> ==================
> There is one very important rule when dealing with nulls. The
> result of
> any operation or comparison, when applied to a null is null. The only
> exception is testing if a value is null.
>
> Example: with the customer table above you could run the
> following queries:
> SELECT * FROM customer WHERE sex='M';
> SELECT * FROM customer WHERE sex<>'M';
> Now you might think this returns all customers, but it will miss those
> where sex is null. You've asked for all rows where the value
> of sex is 'M'
> and all those with values not equal to 'M' but not rows with
> *no value at
> all*
>
> It might help to think of a database as a set of statements
> you *know* to
> be true. A null indicates that you *cannot say anything at
> all* about that
> field. You can't say what it is, you can't say what it isn't,
> you can only
> say there is some information missing.
>
> So, to see all the customers with unknown or inapplicable sex
> you would need:
> SELECT * FROM customer WHERE sex IS NULL;
>
> There are actually three possible results for a test in SQL -
> True (the
> test passed), False (the test failed) and Null (you tested against a
> null). A result of null usually gets treated as False, so
> testing against
> nulls always fails.
>
> If you try to perform an operation on nulls, again the result
> is always
> null. So the results of all of the following are null:
> SELECT 'abc' || null;
> SELECT 1 + null;
> SELECT sqrt(null::numeric);
> The first case can be especially confusing. Concatenating a
> null string to
> a string value will return null, not the original value.
>
>
> Uniqueness and nulls
> ====================
> If you define a unique index on a column it prevents you inserting two
> values that are the same. It does not prevent you inserting
> as many nulls
> as you like. How could it, you don't have a value so it can't
> be the same
> as any other.
>
> Example: We create a table "ta" with a unique constraint on column "b"
> CREATE TABLE ta (
> a int4,
> b varchar(3),
> PRIMARY KEY (a)
> );
> CREATE UNIQUE INDEX ta_b_idx ON ta (b);
> INSERT INTO ta VALUES (1,'aaa'); -- succeeds
> INSERT INTO ta VALUES (2,'bbb'); -- succeeds
> INSERT INTO ta VALUES (3,null); -- succeeds
> INSERT INTO ta VALUES (4,'bbb'); -- fails
> INSERT INTO ta VALUES (5,null); -- succeeds!
>
> Given the definition of what a null is, you only have two
> choices: allow
> multiple nulls or allow no nulls. If you want no nulls,
> define the column
> as NOT NULL when creating the table.
>
>
> Keys and nulls
> ==============
> No column that is part of a primary key can be null. When you define a
> PRIMARY KEY, none of the columns mentioned can take a null value.
> Postgresql makes sure of this by defining the columns as NOT
> NULL for you.
>
> Example: With table "ta" we just created, \d ta will show column a as
> being not null. Otherwise, we could insert rows with a set to null and
> have no way to tell them apart.
>
>
> Subqueries and nulls
> ====================
> Since tests always fail when testing against nulls you can
> have unexpected
> results with sub-queries.
>
> Example: Assume we have a companies table and a diary table.
> Diary entries
> are usually related to a particular company but not always.
> SELECT co_name FROM companies WHERE co_id NOT IN (SELECT
> dy_company FROM
> diary);
> If any row in diary contains a null dy_company then you will get *no
> results*.
> We can expand the query like so:
> WHERE co_id NOT IN (SELECT dy_company FROM diary)
> WHERE co_id NOT IN (1, 2, null, 3...)
> WHERE NOT (co_id=1 OR co_id=2 OR co_id=null OR co_id=3...)
> WHERE NOT (... OR null OR ...)
> WHERE NOT (null)
> WHERE null
>
> You either need to explicitly check for null values, or
> define the column
> in question as NOT NULL.
>
>
> Further Information
> ===================
> Any good relational database book (try something written by Date)
> Bruce's book (link LHS at http://techdocs.postgresql.org)
> My Postgresql Notes (link at http://techdocs.postgresql.org)
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
> |
|
|
| 10) Otto Hirr Re: Case Statement |
|
|
| Just 'cuz you can do something with a language feature does not necessarily mean that it is a good... |
|
|
|
|
|
|
|
Just 'cuz you can do something with a language feature does not necessarily mean that it is a good way to do it. If this is a common query and you have a large dataset, then this is going to be computationally intensive. Why not create a field as part of the table and create a trigger to update the field with the sum of your true bool fields when the record is created or updated. This spreads out this computationally intensive query and then it becomes a simple query... Just some random thoughts... .. Otto
> -----Original Message-----
> From: [email protected: pgsql-sql-...@postgresql.org]
> [email protected: pgsql-sql-...@postgresql.org]On Behalf Of Tom Haddon
> Sent: Wednesday, July 31, 2002 4:33 PM
> To: [email protected: pgsq...@postgresql.org]
> Subject: FW: Case Statement
>
>
> Hi Stephan,
>
> I have a lot of fields, so I'm not sure if a function or case
> is the way to
> go. Basically, I have, say 50 boolean fields that are being
> evaluated, and I
> want to have a column which is the sum of the number of
> "TRUE" values of
> those 50 columns, and then ORDER BY that column. So, for
> example of the 50
> fields to be evaluated, the SELECT statement should return
> records ordered
> by those that match the most number of criteria. Does that
> make sense? Your
> example below may actually work for me, on the other hand:
>
> "case when field1 is true then 1 else 0 end +
> case when field2 is true then 2 else 0 end +
> case when field3 is true then 4 else 0 end
>
> Let's suppose field1 is true and field2, field3 are not,
> would it return 1,
> and if all three are true it would return 7 for the case? If
> so, I think
> that's the way to go, as all this is being dynamically built
> in any case.
>
> Thanks, Tom
>
>
>
> -----Original Message-----
> From: [email protected: pgsql-sql-...@postgresql.org]
> [email protected: pgsql-sql-...@postgresql.org]On Behalf Of Stephan Szabo
> Sent: Wednesday, July 31, 2002 4:17 PM
> To: Tom Haddon
> Cc: [email protected: pgsq...@postgresql.org]
> Subject: Re: [SQL] Case Statement
>
>
> On Wed, 31 Jul 2002, Tom Haddon wrote:
>
> > Hi Folks,
> >
> > Pretty basic one here. I'm trying to do a SELECT statement
> that includes a
> > CASE structure that will be used in the ORDER BY clause,
> and I want the
> CASE
> > structure to evaluate a bunch of criteria and in each case
> increment its
> > value by a certain amount:
> >
> > SELECT id, description CASE
> > field1 IS TRUE THEN CASE=CASE+1
> > field2 IS TRUE THEN CASE=CASE+2
> > END
> > FROM table
> > ORDER BY CASE, description;
> >
> > Am I misunderstanding what CASE can do here, and if so, how
> else do I do
> > what I'm trying to do? I know that that isn't right - any pointers
> > appreciated.
>
> Are you trying to get a 0-3 based on field1 and field2 or some kind of
> aggregate? The first you can do that with something like
> case when field1 is true then 1 else 0 end +
> case when field2 is true then 2 else 0 end
> I think. (Extend for more columns)
>
> Or if you've got like 7-8 columns maybe just make a function that does
> the work for you for clarity.
>
> You'll also need a comma after description and you'll want to
> alias the
> case expression and use that in order by or use the position number.
>
>
>
> ---------------------------(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: majo...@postgresql.org]
>
> |
|
|
| 11) Otto Hirr CVSup Server has the time bug, needs to be upgraded |
|
|
| Please note that as of 07:24PST, 09-19 the cvsup server is old and needs to be upgraded, the... |
|
|
|
|
|
|
|
Please note that as of 07:24PST, 09-19 the cvsup server is old and needs to be upgraded, the following is what I now get when trying to sync: Parsing supfile "cvsup_config" Connecting to postgresql.org Connected to postgresql.org Server software version: REL_16_1 Server postgresql.org has the S1G bug See http://www.polstra.com/projects/freeware/CVSup/s1g/ for details Please notify the maintainer of postgresql.org Refusing update from server with S1G bug When might the server be upgraded? The above page gives a good reason: Outdated clients create a heavy load on the servers, so upgrading to SNAP_16_1e is strongly recommended. Best regards, .. Otto Otto Hirr OLAB Inc 503.617.6595 [email protected: otto...@olabinc.com] |
|
|
| 12) Otto Hirr RE: RFC: PostgreSQL and MySQL comparison. |
|
|
| In a book on marketing warfare (maybe the one by Ries & Trout) there was a question about who was... |
|
|
|
|
|
|
|
> ...
> ... mysql v postgres
> ...
In a book on marketing warfare (maybe the one
by Ries & Trout) there was a question about who
was the competitor:
You own a hotel on a small desert island across
the street from another hotel. The question is
are they your real threat as a competitor and
should you try to drive them down, maybe out of
business? The real competitor is the other,
next, nearest "island" 300 miles away - and not
the hotel across the street. If either of the
hotels go out, the whole island economy falters
and you may go with it. What you really want
is to compete against the other island. If the
business of the hotel across the street goes up,
then your own business is like to grow also.
The issue in this case is who is the real,
significant competitor.
It reminds me about unix. Let see, is it
Sun or HP that has the better unix. Opps, how
about IBM, or Sony, NEC, FreeBSD, NetBSD,
SCO, or ... and opps I forgot Linux, oh how
could I do that? And it would be better
to have start up run scripts where?, what is
the better x-type windowing system?, ...
But, MSDOS was MSDOS, was MSDOS...
and MS Windows was MS Windows, is MS Windows
So who is the real competitor -
HP v Sun v Ibm v ... all unix and all slightly
different in such miniscule amounts (I'll probably
get flamed for that...)
or
unix v MS Windows...
What would have happened if the unix vendors
laid down their NIH and joined each other?
So who is the real, important competitor?
Is it so much important to "compete"
between mysql and postgres, or is it more
important to compete with the proprietary
databases. They all must laugh themselves
silly at times.
But I tell you that there would be a WHOLE
lot more concern if the HUGE amount of brains
and talent on both these projects all laid
down their editors, compilers, os's, and their
deeply entrenched NIH attitude and join
forces with each other. What would that be
like? Is it possible? So you feel like
competing, then compete against your own
self to ask what you could learn from each
other, then change direction and compete
against your COMMON competitor - the
proprietary databases.
Just some rambling thoughts - and certainly
not to try and tit-for-tat war.
Regards,
.. Otto
|
|
|
|
