pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedLots 'o patches
8+ messages / 5 participants
[nested] [flat]
* Lots 'o patches
@ 1998-05-29 14:28 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 1 reply; 8+ messages in thread
From: Thomas G. Lockhart @ 1998-05-29 14:28 UTC (permalink / raw)
To: Postgres Hackers List <hackers@postgresql.org>
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??
2) The name data type will now transparently convert to and from other
string types. For example,
SELECT USER || ' is me';
now works.
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.
I'm planning on writing a section in the new docs discussing type
conversion and coercion, once the behavior becomes set for v6.4.
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...
- Tom
Oh, requires a dump/reload to get the string conversions for the name
data type.
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [HACKERS] Lots 'o patches
@ 1998-05-31 23:31 David Gould <dg@illustra.com>
parent: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 2 replies; 8+ messages in thread
From: dg@illustra.com @ 1998-05-31 23:31 UTC (permalink / raw)
To: lockhart@alumni.caltech.edu; +Cc: hackers@postgreSQL.org
> 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)
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [HACKERS] Lots 'o patches
@ 1998-06-01 02:01 Brett McCormick <brett@work.chicken.org>
parent: David Gould <dg@illustra.com>
1 sibling, 1 reply; 8+ messages in thread
From: Brett McCormick @ 1998-06-01 02:01 UTC (permalink / raw)
To: dg@illustra.com; +Cc: lockhart@alumni.caltech.edu; hackers@postgreSQL.org
I don't quite understand "to get the string conversions for the name
data type" (unless it refers to inserting the appropriate info into
the system catalogs), but dump/reload it isn't a problem at all for
me. It used to really suck, mostly because it was broken, but now it
works great.
On Sun, 31 May 1998, at 16:31:27, David Gould wrote:
> > 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)
>
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [HACKERS] Lots 'o patches
@ 1998-06-01 04:27 Bruce Momjian <maillist@candle.pha.pa.us>
parent: David Gould <dg@illustra.com>
1 sibling, 0 replies; 8+ messages in thread
From: Bruce Momjian @ 1998-06-01 04:27 UTC (permalink / raw)
To: dg@illustra.com; +Cc: lockhart@alumni.caltech.edu; hackers@postgreSQL.org
> 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.
You don't like the fact that upgrades require a dump/reload? I am not
sure we will ever succeed in not requiring that. We change the system
tables too much, because we are a type-neutral system.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [HACKERS] Lots 'o patches
@ 1998-06-01 06:54 David Gould <dg@illustra.com>
parent: Brett McCormick <brett@work.chicken.org>
0 siblings, 1 reply; 8+ messages in thread
From: dg@illustra.com @ 1998-06-01 06:54 UTC (permalink / raw)
To: brett@work.chicken.org; +Cc: lockhart@alumni.caltech.edu; hackers@postgreSQL.org
> I don't quite understand "to get the string conversions for the name
> data type" (unless it refers to inserting the appropriate info into
> the system catalogs), but dump/reload it isn't a problem at all for
> me. It used to really suck, mostly because it was broken, but now it
> works great.
>
> On Sun, 31 May 1998, at 16:31:27, David Gould wrote:
>
> > > 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.
One of the Illustra customers moving to Informix UDO that I have had the
pleasure of working with is Egghead software. They sell stuff over the web.
24 hours a day. Every day. Their database takes something like 20 hours to
dump and reload. The last time they did that they were down the whole time
and it made the headline spot on cnet news. Not good. I don't think they
want to do it again.
If we want postgresql to be usable by real businesses, requiring downtime is
not acceptable.
A proper upgrade would just update the catalogs online and fix any other
issues without needing a dump / restore cycle.
As a Sybase customer once told one of our support people in a very loud voice
"THIS is NOT a "Name and Address" database. WE SELL STOCKS!".
-dg
David Gould dg@illustra.com 510.628.3783 or 510.305.9468
Informix Software 300 Lakeside Drive Oakland, CA 94612
- A child of five could understand this! Fetch me a child of five.
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [HACKERS] Lots 'o patches
@ 1998-06-01 14:24 Bruce Momjian <maillist@candle.pha.pa.us>
parent: David Gould <dg@illustra.com>
0 siblings, 1 reply; 8+ messages in thread
From: Bruce Momjian @ 1998-06-01 14:24 UTC (permalink / raw)
To: dg@illustra.com; +Cc: brett@work.chicken.org; lockhart@alumni.caltech.edu; hackers@postgreSQL.org
> One of the Illustra customers moving to Informix UDO that I have had the
> pleasure of working with is Egghead software. They sell stuff over the web.
> 24 hours a day. Every day. Their database takes something like 20 hours to
> dump and reload. The last time they did that they were down the whole time
> and it made the headline spot on cnet news. Not good. I don't think they
> want to do it again.
>
> If we want postgresql to be usable by real businesses, requiring downtime is
> not acceptable.
>
> A proper upgrade would just update the catalogs online and fix any other
> issues without needing a dump / restore cycle.
>
> As a Sybase customer once told one of our support people in a very loud voice
> "THIS is NOT a "Name and Address" database. WE SELL STOCKS!".
That is going to be difficult to do. We used to have some SQL scripts
that could make the required database changes, but when system table
structure changes, I can't imagine how we would migrate that without a
dump/reload. I suppose we could keep the data/index files with user data,
run initdb, and move the data files back, but we need the system table
info reloaded into the new system tables.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 8+ messages in thread
* RE: [HACKERS] Lots 'o patches
@ 1998-06-02 00:44 Stupor Genius <stuporg@erols.com>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 1 reply; 8+ messages in thread
From: Stupor Genius @ 1998-06-02 00:44 UTC (permalink / raw)
To: pgsql-hackers
>
> That is going to be difficult to do. We used to have some SQL scripts
> that could make the required database changes, but when system table
> structure changes, I can't imagine how we would migrate that without a
> dump/reload. I suppose we could keep the data/index files with user data,
> run initdb, and move the data files back, but we need the system table
> info reloaded into the new system tables.
If the tuple header info doesn't change, this doesn't seem that tough.
Just do a dump the pg_* tables and reload them. The system tables are
"small" compared to the size of user data/indexes, no?
Or is there some extremely obvious reason that this is harder than it
seems?
But then again, what are the odds that changes for a release will only
affect system tables so not to require a data dump? Not good I'd say.
darrenk
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [HACKERS] Lots 'o patches
@ 1998-06-02 05:54 David Gould <dg@illustra.com>
parent: Stupor Genius <stuporg@erols.com>
0 siblings, 0 replies; 8+ messages in thread
From: dg@illustra.com @ 1998-06-02 05:54 UTC (permalink / raw)
To: stuporg@erols.com; +Cc: pgsql-hackers
>
> >
> > That is going to be difficult to do. We used to have some SQL scripts
> > that could make the required database changes, but when system table
> > structure changes, I can't imagine how we would migrate that without a
> > dump/reload. I suppose we could keep the data/index files with user data,
> > run initdb, and move the data files back, but we need the system table
> > info reloaded into the new system tables.
>
> If the tuple header info doesn't change, this doesn't seem that tough.
> Just do a dump the pg_* tables and reload them. The system tables are
> "small" compared to the size of user data/indexes, no?
I like this idea.
> Or is there some extremely obvious reason that this is harder than it
> seems?
>
> But then again, what are the odds that changes for a release will only
> affect system tables so not to require a data dump? Not good I'd say.
Hmmm, not bad either, especially if we are a little bit careful not to
break existing on disk structures, or to make things downward compatible.
For example, if we added a b-tree clustered index access method, this should
not invalidate all existing tables and indexes, they just couldn't take
advantage of it until rebuilt.
On the other hand, if we decided to change to say 64 bit oids, I can see
a reload being required.
I guess that in our situation we will occassionally have changes that require
a dump/load. But this should really only be required for the addition of a
major feature that offers enough benifit to the user that they can see that
it is worth the pain.
Without knowing the history, the impression I have formed is that we have
sort of assumed that each release will require a dump/load to do the upgrade.
I would like to see us adopt a policy of trying to avoid this unless there
is a compelling reason to make an exception.
-dg
David Gould dg@illustra.com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
"Don't worry about people stealing your ideas. If your ideas are any
good, you'll have to ram them down people's throats." -- Howard Aiken
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~1998-06-02 05:54 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1998-05-29 14:28 Lots 'o patches Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-05-31 23:31 ` David Gould <dg@illustra.com>
1998-06-01 02:01 ` Brett McCormick <brett@work.chicken.org>
1998-06-01 06:54 ` David Gould <dg@illustra.com>
1998-06-01 14:24 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-06-02 00:44 ` Stupor Genius <stuporg@erols.com>
1998-06-02 05:54 ` David Gould <dg@illustra.com>
1998-06-01 04:27 ` Bruce Momjian <maillist@candle.pha.pa.us>
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