char types gone.
Have managed to delete char2,4,8 and 16. The char16 was tricky
since it was still one of the builtins. Removed fine everywhere
but the bootstrap code. Had to leave a dummy entry in the Procid
array so all of the types after char16 would be indexed correctly.
Could remove this dummy by moving types 21-30 down one, but that
would entail renumbering the catalog. With that in mind, I can
live with a filler entry in an array. Heaven knows there are bigger
and badder hacks elsewhere in the code dying to be discovered. :)
Three points now...regression tests, docs and interfaces.
1. Regression tests make very extensive use of char16. Seems to
me that these should be changed to a name. Same for tutorial and
any other example references in the code. Seem ok?
2. I'll take my best shot at the docs.
3. Also take a look/see at the interfaces that reference the char16.
Perhaps would be better for me to contact the maintainers of those
interfaces as they would know what to do better than I.
Once I do one and two, I'll submit the patch.
darrenk
On Mon, 23 Mar 1998, Zeugswetter Andreas wrote:
1. Regression tests make very extensive use of char16. Seems to
me that these should be changed to a name. Same for tutorial and
any other example references in the code. Seem ok?** down sinks the mast of the old postquel, there, can you see it blink
in the deep green water ? ** ** nostalgia on my face ** I think I forgot
to mention my nicest hobby, sailing **
Okay, this one has me...what benefit is there to char16 over
char(16)? Why, in the first place, was it implemented as char16 anyway?
As for "down sinks the mast"...so far as I've been able to tell,
we have *never* removed anything that wasn't replaced by a better way of
doing it (time travel with triggers)...we didn't leave anyone floundering
for a solution to it, we provided it...but now, its not forced on
*everyone*, just on those databases/tables that require it...
Same functionality, better performance...
Have managed to delete char2,4,8 and 16.
Three points now...regression tests, docs and interfaces.1. Regression tests make very extensive use of char16. Seems to
me that these should be changed to a name. Same for tutorial and
any other example references in the code. Seem ok?
Any reason not to use "text" for these cases? Or even varchar()? "name"
is probably really only an internal Postgres type. We should have a
regression test for it if we don't already. Let me know if you want me
to help...
2. I'll take my best shot at the docs.
Where? The man pages or the sgml sources? I'm shooting for getting the
sgml sources right, and obsoleting the man page _sources_, regenerating
them from the sgml instead.
- Tom
As for "down sinks the mast"...so far as I've been able to tell,
we have *never* removed anything that wasn't replaced by a better way
of doing it (time travel with triggers)...we didn't leave anyone
floundering for a solution to it, we provided it...but now, its not
forced on *everyone*, just on those databases/tables that require
it...
Same functionality, better performance...
Ah, he wasn't complaining, just saluting a retiring soldier :)
1. Regression tests make very extensive use of char16. Seems to
me that these should be changed to a name. Same for tutorial and
any other example references in the code. Seem ok?
** down sinks the mast of the old postquel, there, can you see it blink in the deep green water ? **
** nostalgia on my face ** I think I forgot to mention my nicest hobby, sailing **
I think char(16) would be the correct replacement in the regression tests
and tutorial, since this is what we want people to use. name is more or less
an internal type for system catalogs and the like. I would not propagate it too much.
Of course regress.c would need a little patch then, but no big deal.
Andreas
Import Notes
Resolved by subject fallback
On Mon, 23 Mar 1998, Zeugswetter Andreas wrote:
As for "down sinks the mast"...so far as I've been able to tell,
we have *never* removed anything that wasn't replaced by a better way of
doing it (time travel with triggers)...we didn't leave anyone floundering
for a solution to it, we provided it...but now, its not forced on
*everyone*, just on those databases/tables that require it...Same functionality, better performance...
** up raises the ulralight carbon ultra high speed mast, I like that streamline,
of course for this the old wooden one had to go ;-) **
Okay...just checking. I've heard one major complaint about PostgreSQL in
the past concerning the fact that we are just gutting it and "taking the
Postgres out of PostgreSQL", which I feel is an unfair assessment...
As your analogy puts it above, we've replaced key components of the old
"wooden, three mast'r" with a more sleek and streamlined "carbon fiber
mast"...but that new mast holds the same sails, just gets us to the finish
line faster...
If anyone feels that we've removed something that was really unique and
not replacedit with something better/faster, or provided a work around,
please let us know...in most cases, there is alot of discussion both here,
and in a private list, over whether we go forward with a modification or
not, especially something that is part of the *base* structure of the
system.
We have an *Open* development forum here...if you don't like the route
something is (or appears to be) going, let us know...give us strong
arguements for/against...but don't wait until the discussion is done and
everyone is in agreement before popping up...:(
The Hermit Hacker wrote:
1. Regression tests make very extensive use of char16. Seems to
me that these should be changed to a name. Same for tutorial and
any other example references in the code. Seem ok?** down sinks the mast of the old postquel, there, can you see it blink
in the deep green water ? ** ** nostalgia on my face ** I think I forgot
to mention my nicest hobby, sailing **Okay, this one has me...what benefit is there to char16 over
char(16)? Why, in the first place, was it implemented as char16 anyway?
char16 was there before varlena's got implemented, the basis for char(16).
There is no significant advantage of char16 over char(16) any more.
As for "down sinks the mast"...so far as I've been able to tell,
we have *never* removed anything that wasn't replaced by a better way of
doing it (time travel with triggers)...we didn't leave anyone floundering
for a solution to it, we provided it...but now, its not forced on
*everyone*, just on those databases/tables that require it...
Same functionality, better performance...
** up raises the ulralight carbon ultra high speed mast, I like that streamline,
of course for this the old wooden one had to go ;-) **
This was never intended as a critique, I think it is good that char2-16 goes.
Of course I stick to my real message of this thread:
replace the char16 stuff in the tutorial and the regression tests with char(16)
or even varchar(16) but not with name.
Andreas
Import Notes
Resolved by subject fallback
You seem to be getting me wrong, right from the start. I appreciate your work on removing
char2-char16. I also think it is the correct step. You have the hackers behind you, the discussion was
about 2 - 3 weeks ago. I was part of it. There are three things that will need documentation:
1. the replacement for char16 is char(16)
2. char(16) gives and ignores trailing blanks
I don't think this is true.
--
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)On Mon, 23 Mar 1998, Zeugswetter Andreas wrote:
You seem to be getting me wrong, right from the start. I appreciate your work on removing
char2-char16. I also think it is the correct step. You have the hackers behind you, the discussion was
about 2 - 3 weeks ago. I was part of it. There are three things that will need documentation:
1. the replacement for char16 is char(16)
2. char(16) gives and ignores trailing blanks
3. refer to VARDATA(someparameter) to get your (char *) in a C functionThomas wrote:
Same functionality, better performance...
Ah, he wasn't complaining, just saluting a retiring soldier :)
This description makes me happy. It is exactly what I wanted to express.
Gosh, I sure did not want to nag, sorry if that is how you interpreted it.
*grin* No, I understood that from the second one you sent, I just
want to make sure that anyone out there that might feel we've over-gut'd
isn't afraid to speak up...
*both feet buried in mouth*? :)
You seem to be getting me wrong, right from the start. I appreciate your work on removing
char2-char16. I also think it is the correct step. You have the hackers behind you, the discussion was
about 2 - 3 weeks ago. I was part of it. There are three things that will need documentation:
1. the replacement for char16 is char(16)
2. char(16) gives and ignores trailing blanks
3. refer to VARDATA(someparameter) to get your (char *) in a C function
Thomas wrote:
Same functionality, better performance...
Ah, he wasn't complaining, just saluting a retiring soldier :)
This description makes me happy. It is exactly what I wanted to express.
Gosh, I sure did not want to nag, sorry if that is how you interpreted it.
Andreas
Import Notes
Resolved by subject fallback
Have managed to delete char2,4,8 and 16.
Three points now...regression tests, docs and interfaces.1. Regression tests make very extensive use of char16. Seems to
me that these should be changed to a name. Same for tutorial and
any other example references in the code. Seem ok?Any reason not to use "text" for these cases? Or even varchar()? "name"
is probably really only an internal Postgres type. We should have a
regression test for it if we don't already. Let me know if you want me
to help...
I think the 'name' type should be considered an internal type only and
mentioned as such wherever it is documented. It's only purpose seems
to be for a consistent length to internal names and it does that rather
well. User's would be better served with the other, varlena-based, types.
Any examples I was going to convert from char16 to char(16). There are a
couple of mentions of the char16 struct that will have to be integrated
or changed to reference the varlena struct.
Finally, I'm redoing the char16 regression test for name.
2. I'll take my best shot at the docs.
Where? The man pages or the sgml sources? I'm shooting for getting the
sgml sources right, and obsoleting the man page _sources_, regenerating
them from the sgml instead.
Do you want patches against doc/src/sgml/*? The man pages references were
few, so they were easy to change for consistency sake then til they drop
into the bit bucket. Changed a few references in the userguide too.
Only have to tidy up the docs and I'll submit the patch.
darrenk
Import Notes
Resolved by subject fallback
Okay...just checking. I've heard one major complaint about PostgreSQL in
the past concerning the fact that we are just gutting it and "taking the
Postgres out of PostgreSQL", which I feel is an unfair assessment...As your analogy puts it above, we've replaced key components of the old
"wooden, three mast'r" with a more sleek and streamlined "carbon fiber
mast"...but that new mast holds the same sails, just gets us to the finish
line faster...If anyone feels that we've removed something that was really unique and
not replacedit with something better/faster, or provided a work around,
please let us know...in most cases, there is alot of discussion both here,
and in a private list, over whether we go forward with a modification or
not, especially something that is part of the *base* structure of the
system.We have an *Open* development forum here...if you don't like the route
something is (or appears to be) going, let us know...give us strong
arguements for/against...but don't wait until the discussion is done and
everyone is in agreement before popping up...:(
If for posterity alone, I'm willing to move the char[24816] code to contrib.
I already have the create and load statements in an sql file, just have to
polish the Makefile a little. If not with the distribution, then perhaps
this could be at the web site for downloading.
Having the code available for loading might be easier for persons such as
Tatsuo instead of having their users complain of something disappearing.
My only intention in doing this is to lighten up the postgres core, not to
force others to change their existing code.
darrenk
Import Notes
Resolved by subject fallback
On Mon, 23 Mar 1998, Darren King wrote:
If for posterity alone, I'm willing to move the char[24816] code to contrib.
I already have the create and load statements in an sql file, just have to
polish the Makefile a little. If not with the distribution, then perhaps
this could be at the web site for downloading.Having the code available for loading might be easier for persons such as
Tatsuo instead of having their users complain of something disappearing.My only intention in doing this is to lighten up the postgres core, not to
force others to change their existing code.
Unless there is a proven performance boost to removing things from
the core, which, at this point in time, hasn't been demonstrated,
*nothing* should be removed from the core...
...in fact, I want to bring in the IP code from contrib as part of
the core yet...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
If for posterity alone, I'm willing to move the char[24816] code to contrib.
I already have the create and load statements in an sql file, just have to
polish the Makefile a little. If not with the distribution, then perhaps
this could be at the web site for downloading.Having the code available for loading might be easier for persons such as
Tatsuo instead of having their users complain of something disappearing.My only intention in doing this is to lighten up the postgres core, not to
force others to change their existing code.Unless there is a proven performance boost to removing things from
the core, which, at this point in time, hasn't been demonstrated,
*nothing* should be removed from the core......in fact, I want to bring in the IP code from contrib as part of
the core yet...
Would be nice if stuff like that (and the money and geometrics) could be
compiled in in the same manner that Apache is a basic web server that lets
you pick and choose modules/features you want to build into it.
I don't know how big of a performance boost it provides in the cache, but
removing the functions associated with the char types shrank the pg_proc
table from 906 to 842 entries or a bit over 7%.
Want to shrink it further? Of those remaining 842, _230_ are for the geometric
types! Throw in 25 more for the cash/money functions. Bloat city if you
never use these things. Thirty percent could be moved out to contrib and
not missed by most postgres users.
I think a reasonable goal is to provide an sql server that meets the current sql
standard with the possibility of having other types and functionality available
as modules. These modules could be made into the template1 at compile time
or made and installed on a per-database basis. Make your server and database
with whatever you want in it.
Why force others to have functionality 'x', 'y' and 'z' when they only want 'y'?
darrenk
Import Notes
Resolved by subject fallback
Would be nice if stuff like that (and the money and geometrics) could be
compiled in in the same manner that Apache is a basic web server that lets
you pick and choose modules/features you want to build into it.I don't know how big of a performance boost it provides in the cache, but
removing the functions associated with the char types shrank the pg_proc
table from 906 to 842 entries or a bit over 7%.Want to shrink it further? Of those remaining 842, _230_ are for the geometric
types! Throw in 25 more for the cash/money functions. Bloat city if you
never use these things. Thirty percent could be moved out to contrib and
not missed by most postgres users.
Yes, but if they are never referenced, the cache is empty for those
types. Unless there is some performance change with their removal, why
remove them? Disk space of binary?
--
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)On Mon, 23 Mar 1998, Bruce Momjian wrote:
Would be nice if stuff like that (and the money and geometrics) could be
compiled in in the same manner that Apache is a basic web server that lets
you pick and choose modules/features you want to build into it.I don't know how big of a performance boost it provides in the cache, but
removing the functions associated with the char types shrank the pg_proc
table from 906 to 842 entries or a bit over 7%.Want to shrink it further? Of those remaining 842, _230_ are for the geometric
types! Throw in 25 more for the cash/money functions. Bloat city if you
never use these things. Thirty percent could be moved out to contrib and
not missed by most postgres users.Yes, but if they are never referenced, the cache is empty for those
types. Unless there is some performance change with their removal, why
remove them? Disk space of binary?
I have to agree here...unless a noticeable performance improvement
can be demonstrated, I really don't like a trend that moves towards
removing core features that make us unique, just cause it makes a table
just a little smaller...*shrug*
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Mon, 23 Mar 1998, The Hermit Hacker wrote:
On Mon, 23 Mar 1998, Bruce Momjian wrote:
Would be nice if stuff like that (and the money and geometrics) could be
compiled in in the same manner that Apache is a basic web server that lets
you pick and choose modules/features you want to build into it.I don't know how big of a performance boost it provides in the cache, but
removing the functions associated with the char types shrank the pg_proc
table from 906 to 842 entries or a bit over 7%.Want to shrink it further? Of those remaining 842, _230_ are for the geometric
types! Throw in 25 more for the cash/money functions. Bloat city if you
never use these things. Thirty percent could be moved out to contrib and
not missed by most postgres users.Yes, but if they are never referenced, the cache is empty for those
types. Unless there is some performance change with their removal, why
remove them? Disk space of binary?I have to agree here...unless a noticeable performance improvement
can be demonstrated, I really don't like a trend that moves towards
removing core features that make us unique, just cause it makes a table
just a little smaller...*shrug*
I'm also thinking about JDBC. If you remove some features out of the core,
and reorganise what OID's are associated with the types, then we would
have a big performance hit when the driver starts up, and possibly make
the driver even larger than it is now.
--
Peter T Mount petermount@earthling.net or pmount@maidast.demon.co.uk
Main Homepage: http://www.demon.co.uk/finder
Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk
On Tue, 24 Mar 1998, Peter T Mount wrote:
I'm also thinking about JDBC. If you remove some features out of the core,
and reorganise what OID's are associated with the types, then we would
have a big performance hit when the driver starts up, and possibly make
the driver even larger than it is now.
From discussions that the core have had on this topic over the
past couple of weeks, I think it will take *alot* to convince us to remove
core features.
char2/4/8/16 disappears *only* because they were redundant...it
had nothing to do with reducing the sizes of tables...char2 maps to
char(2), so why have both. Stuff like the geometric types aren't
redundant...they are themselves the "base" types...
Once v6.3.1 is finished up, I'm going to be looking at merging in
the ip_and_mac contrib stuff, and I think that Thomas is considering
moving the 64bit stuff into the core from contrib...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
I think Darren brings up very good points here. This seems to be the model
that many people are going to when developing large systems. This would
also help in maintaning the the system.
Wayne
On Mon, 23 Mar 1998, Darren King wrote:
Show quoted text
...in fact, I want to bring in the IP code from contrib as part of
the core yet...Would be nice if stuff like that (and the money and geometrics) could be
compiled in in the same manner that Apache is a basic web server that lets
you pick and choose modules/features you want to build into it.I don't know how big of a performance boost it provides in the cache, but
removing the functions associated with the char types shrank the pg_proc
table from 906 to 842 entries or a bit over 7%.Want to shrink it further? Of those remaining 842, _230_ are for the geometric
types! Throw in 25 more for the cash/money functions. Bloat city if you
never use these things. Thirty percent could be moved out to contrib and
not missed by most postgres users.I think a reasonable goal is to provide an sql server that meets the current sql
standard with the possibility of having other types and functionality available
as modules. These modules could be made into the template1 at compile time
or made and installed on a per-database basis. Make your server and database
with whatever you want in it.Why force others to have functionality 'x', 'y' and 'z' when they only want 'y'?
darrenk
Darren King wrote:
Would be nice if stuff like that (and the money and geometrics) could be
compiled in in the same manner that Apache is a basic web server that lets
you pick and choose modules/features you want to build into it.I don't know how big of a performance boost it provides in the cache, but
removing the functions associated with the char types shrank the pg_proc
table from 906 to 842 entries or a bit over 7%.Want to shrink it further? Of those remaining 842, _230_ are for the geometric
types! Throw in 25 more for the cash/money functions. Bloat city if you
never use these things. Thirty percent could be moved out to contrib and
not missed by most postgres users.I think a reasonable goal is to provide an sql server that meets the current sql
standard with the possibility of having other types and functionality available
as modules. These modules could be made into the template1 at compile time
or made and installed on a per-database basis. Make your server and database
with whatever you want in it.
The problem with the contrib stuff is that most users find it too
difficult to dig around in that dir and make and install stuff. The
"contrib" name also give me the feeling that this is unsupported
stuff/beta/not-to-be-used-in-production/to-be-removed etc.
The nicest thing would be if contrib was changed to "modules", and
everything was compiled and installed in /usr/local/pgsql/modules/.
Then the user could install them by typing "INSMOD ORACLE" and then
/usr/local/pgsql/modules/oracle/insmod.sql would be executed and
install shared libraries and sql commands. "RMMOD ORACLE" would
do the opposite. Just like Linux modules.
Perhaps it would even be possible to autoload modules if the modules
directories contains a file with commands/functions listed, which
would be searched automagically...
This is the idea:
psql-> SET MODULES TO AUTOLOAD;
NOTICE: 100 Modules will now load automagically.
psql-> SELECT MYFUNKYFUNC('hello');
NOTICE: 202 Unknown function 'MYFUNKYFUNC(text)'
NOTICE: 100 Module 'MYFUNCTIONS' loaded.
myfunkyfunc
-------------------
the word is 'hello'
(1 row)
psql-> INSMOD ORACLE;
NOTICE: 100 Module 'ORACLE' loaded.
NOTICE: 110 Module description: Oracle(tm) compatability module. Version
1.0.
psql-> LSMOD;
NOTICE: 100 MYFUNCTIONS ORACLE
psql-> RMMOD VERBOSE MYFUNCTIONS;
NOTICE: 100 Module 'MYFUNCTIONS' removed.
NOTICE: 120 Functions removed: Myfunkyfunc(text) Myotherfunc(int)
Mylastfunc(float)
NOTICE: 120 Commands removed: Myfunkycommand
Is it possible to register commands dynamically in the parser?
/* m */
