From: dg@illustra.com
To: lockhart@alumni.caltech.edu
Cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] Lots 'o patches
Date: Sun, 31 May 1998 16:31:27 -0700 (PDT)
Message-ID: <9805312331.AA27572@hawk.illustra.com> (raw)
In-Reply-To: <356EC609.991710C8@alumni.caltech.edu>
> I've just committed a bunch of patches, mostly to help with parsing and
> type conversion. The quick summary:
>
> 1) The UNION construct will now try to coerce types across each UNION
> clause. At the moment, the types are converted to match the _first_
> select clause, rather than matching the "best" data type across all the
> clauses. I can see arguments for either behavior, and I'm pretty sure
> either behavior can be implemented. Since the first clause is a bit
> "special" anyway (that is the one which can name output columns, for
> example), it seemed that perhaps this was a good choice. Any comments??
I think this is good. The important thing really is that we have a
consistant "story" we can tell about how and why it works so that a user can
form a mental model of the system that is useful when trying to compose
a query. Ie, the principal of least surprise.
The story "the first select picks the names and types for the columns and
the other selects are cooerced match" seems quite clear and easy to understand.
The story "the first select picks the names and then we consider all the
possible conversions throughout the other selects and resolve them using
the type heirarchy" is not quite as obvious.
What we don't want is a story that approximates "we sacrifice a goat and
examine the entrails".
> 2) The name data type will now transparently convert to and from other
> string types. For example,
>
> SELECT USER || ' is me';
>
> now works.
Good.
> 3) A regression test for UNIONs has been added. SQL92 string functions
> are now included in the "strings" regression test. Other regression
> tests have been updated, and all tests pass on my Linux/i686 box.
Very good.
> I'm planning on writing a section in the new docs discussing type
> conversion and coercion, once the behavior becomes set for v6.4.
Even better.
> I think the new type conversion/coercion stuff is pretty solid, and I've
> tested as much as I can think of wrt behavior. It can benefit from
> testing by others to uncover any unanticipated problems, so let me know
> what you find...
Will do.
> - Tom
>
> Oh, requires a dump/reload to get the string conversions for the name
> data type.
Ooops. I guess we need to add "make a useful upgrade procedure" to our
todo list. I am not picking on this patch, it is a problem of long standing
but as we get into real applications it will become increasingly
unacceptable.
-dg
David Gould dg@illustra.com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
"Of course, someone who knows more about this will correct me if I'm wrong,
and someone who knows less will correct me if I'm right."
--David Palmer (palmer@tybalt.caltech.edu)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: dg@illustra.com, lockhart@alumni.caltech.edu, hackers@postgreSQL.org
Subject: Re: [HACKERS] Lots 'o patches
In-Reply-To: <9805312331.AA27572@hawk.illustra.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox