Re: [HACKERS] PostgreSQL and SOAP, suggestions?

[cbbrowne]

> I have been planning to "test" the whole thing with a few .NET 
> applications. I am currently using expat to parse the output to ensure 
> that it all works correcty.

That, unfortunately, probably implies that your implementation is almost 
totally non-interoperable.

You should put out of your mind the notion of being "correct."  Being 
"correct" is pretty irrelevant if 80% of the requests that come from a VB.NET 
client fail because Microsoft implemented part of their request differently 
than what you interpreted as "correct."

The point is that "correctness" isn't the thing you need to aim for; what you 
should aim for is interoperability with the important client implementations.

SOAP::Lite, .NET, probably some Java ones, C++ ones, and such.

Nobody does "correctness" testing; they do interoperability tests where they 
try to submit requests to Apache AXIS, .NET, WebSphere, and the lot of other 
important implementations.  If you're testing a server (as is the case here), 
then the point is to run tests with a bunch of clients.

Head to the SOAP::Lite and Axis projects; you'll see matrices describing this 
sort of thing...
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://www.ntlug.org/~cbbrowne/advocacy.html
"Fear leads to anger. Anger leads to hate. Hate leads to using Windows
NT for mission-critical applications."  --- What Yoda *meant* to say


---(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] PostgreSQL and SOAP, suggestions?

[cbbrowne]

> [EMAIL PROTECTED] kirjutas N, 03.04.2003 kell 02:01:
> > mlw wrote:
> > > I think you are interpreting the spec a bit too restrictively. The 
> > > syntax is fairly rigid, but the spec has a great degree of flexibility. 
> > > I agree that, syntactically, it must work through a parser, but there is 
> > > lots of room to be flexible.
> > 
> > This is /exactly/ the standard problem with SOAP.
> > 
> > There is enough "flexibility" that there are differing approaches
> > associated, generally speaking, with "IBM versus Microsoft" whereby it's
> > easy to generate SOAP requests that work fine with one that break with
> > the other.
> 
> Do you know of some:
> 
> a) standard conformance tests
> 
> b) recommended best practices for being compatible with all mainstream
> implementations (I'd guess a good approach would be to generate very
> strictly conformant code but accept all that you can, even if against
> pedantic reading of the spec)

The problem with a) is that SOAP, unlike CORBA, doesn't have the notion of 
standardized language bindings.  That makes it tough to be sure that your 
implementation is "standard" in any meaningful way in the first place.

The "best practices" have involved scripting up interoperability tests where 
they construct sets of functions with varying data types and verify that "my 
client implementation can talk to your server implementation," and vice-versa.

And when you run into problems, you chip off bits of code until the block of 
stone starts looking like an elephant.

In order to have confidence of interoperability, you have to test your client 
library against all the servers you care about, or vice-versa.  That's 
definitely not the same thing as being a "conformance" test.

Trying to be "really strict" doesn't seem to be a viable strategy, as far as I 
can see...
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www3.sympatico.ca/cbbrowne/wp.html
"The cost of living has just gone up another dollar a quart."  
-- W.C. Fields


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] PostgreSQL and SOAP, suggestions?

[cbbrowne]

mlw wrote:
> I think you are interpreting the spec a bit too restrictively. The 
> syntax is fairly rigid, but the spec has a great degree of flexibility. 
> I agree that, syntactically, it must work through a parser, but there is 
> lots of room to be flexible.

This is /exactly/ the standard problem with SOAP.

There is enough "flexibility" that there are differing approaches
associated, generally speaking, with "IBM versus Microsoft" whereby it's
easy to generate SOAP requests that work fine with one that break with
the other.

For a pretty simple example of a longstanding bug that has never been
fixed, see:
<http://sourceforge.net/tracker/index.php?func=detail&aid=559324&group_id=26590&atid=387667>

The precis:

The SOAP implementation used by the XMethods folks to publish stock
prices is buggy, rejecting perfectly legitimate messages submitted using
ZSI (a Python SOAP implementation).

The bug isn't with ZSI; it is quite clearly with the server, apparently
implemented in Java using one of the EJB frameworks.  

In practice, what happens is that since that service is fairly popular,
particularly for sample applications, the implementors of SOAP libraries
wind up coding around the bugs.

The problem is that it gets difficult to tell the difference between
bugs and variations in interpretations of the standards.

If the specs were more strictly defined, it would be a lot easier to use
SOAP, because you wouldn't be left puzzling over whether the
interoperability problems you're having are:

 a) Problems with the client;
 b) Problems with the server;
 c) Problems with interpretation of specs;
 d) ...

The vast degree to which messages can get rewritten behind your back
adds to the fun.

Of course, it's only fun if you *enjoy* having interoperability
problems...
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www.ntlug.org/~cbbrowne/soap.html
He who laughs last thinks slowest. 


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Newbie: problem Connecting to Server

[cbbrowne]

"Ferindo Middleton Jr" <[EMAIL PROTECTED]> wrote:
> I'm running Redhat Linux 8. I have registration to the Redhat
> Network so I'm probably running the latest version of postgresql
> available. I also have Redhat Databse v2.1 installed, but whenever I
> try to start a session, I get the following error message:
>
> psql: could not connect to server: No such file or directory
> Is the server running locally and accepting
> connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
>
> Please help me configure my system so that I can connect and begin to use
> postgresql.

Have you checked to see if it is actually running?  I rather expect
that it isn't.

I think RHAT distributes GUIfied tools to manage services started via
init.d, so that even if you are afraid of Unix, you should be able to
see what it's doing.

And it's quite unlikely that RHAT has packaged the very latest
version; the fact that they are numbering things independently is
quite irritating as it makes it more difficult to ascertain what
version it actually is.
-- 
output = ("cbbrowne" "@acm.org")
http://www3.sympatico.ca/cbbrowne/rdbms.html
"...while   I   know  many   people   who   emphatically  believe   in
reincarnation, I have  never met or read one  who could satisfactorily
explain population growth." -- Spider Robinson


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] PostgreSQL and SOAP, version 7.4/8.0

[cbbrowne]

Jason wrote:
> If you can support xmlrpc instead, you'll save yourself a lot of headaches.

XML-RPC has three merits over SOAP:

 1.  It's a simple specification, and thus readily implemented.

 2.  Microsoft and IBM aren't fighting over control over it, so it's
 not suffering from the "we keep adding pseudo-standards to it"
 problem.  (Which further complicates the specifications.)
 You can have a /complete/ implementation of XML-RPC, whereas,
 for SOAP, you can hold ghastly long arguments as to what SOAP
 means, anyways.

 3.  There's a (perhaps not "standard", but definitely widely
 implemented) scheme for bundling multiple XML-RPC requests into
 one message, which improves latency a LOT for small messages.

Of course, CORBA has actually been quite formally standardized, suffers
from many fairly interoperable implementations, and is rather a lot less
bloated than any of the XML-based schemes.  It might be worth trying,
too...
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://cbbrowne.com/info/soap.html
I just got skylights put in my place. The people who live above me are
furious.


---(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] XML ouput for psql

[cbbrowne]

> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > I also think that psql is not the place to implement something like this.
> 
> Agreed.
> 
> > It's most likely best put in the backend, as a function like
> > xmlfoo('select * from t1;')

> That seems a little bizarre.  Wouldn't we want to have a switch that
> just flips the SELECT output format from one style to the other?

Ah, but this approach has the merit that it doesn't require pushing out
a completely new set of tools.

> This is also a good time to stop and ask whether the frontend/backend
> protocol needs to change to support this.  Not having read the spec, I
> have no idea what the low-level transport needs are for XML output,
> but I suspect our present protocol is not it ...

That could be; there's enough variation in what one might want to do
with XML that it is not trivial to suggest an 'ideal' answer.

We have already seen the proposal of:





I would rather prefer something like:

 
   b d f
   
 
   c d f
   
 
   d d f
   


(Note that both approaches are quite rational possibilities.)

I'd think that the "protocol" would involve passing back a row-as-string
for each row in the result set.
--
output = ("cbbrowne" "@cbbrowne.com")
http://www.ntlug.org/~cbbrowne/xml.html
"There are two major products that come out of Berkeley: LSD and Unix.
We don't believe this to be a coincidence." - Jeremy S. Anderson

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] [PATCHES] XML ouput for psql

[cbbrowne]

> [EMAIL PROTECTED] writes:
> 
> > I don't agree with this: XML and XHTML are two different things.
> 
> No one claimed anything to the contrary.
> 
> > We could certainly upgrade the HTML portion, but I am pretty sure that
> > the XML standard calls for this format:
> >
> > data here
> 
> The XML standard does not call for any table format.  But a number of
> table formats have been established within the XML framework.  Some of
> them are formatting-oriented (e.g., the HTML model, or CALS which is used
> in DocBook) and some of them are processing-oriented (e.g., SQL/XML).
> Which do we need?  And which do we need from psql in particular (keeping
> in mind that psql is primarily for interactive use and shell-scripting)?
> In any case, it should most likely be a standard table model and not a
> hand-crafted one.

I would expect XML output to be based on whatever the tree of data
contained.

If the tree is to be rewritten, then this would mean having some sort of
transformation engine in PostgreSQL that you would have to program.

If I want a CALS table, then I'll push CALS table data into the
database.

If I'm storing a GnuCash chart of accounts in PostgreSQL, I am
ludicrously uninterested in seeing it rewritten for some sort of
physical layout.  Spit out the tags that are stored in the database, not
some rewriting of it.
--
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://cbbrowne.com/info/linuxdistributions.html
(1) Sigs are preceded by the "sigdashes" line, ie "\n-- \n" (dash-dash-space).
(2) Sigs contain at least the name and address of the sender in the first line.
(3) Sigs are at most four lines and at most eighty characters per line.

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] Yet another open-source benchmark

[cbbrowne]

> OSDL has just come out with a set of open-source database benchmarks:
> http://www.osdl.org/projects/performance/
> 
> The bad news:
> "This tool kit works with SAP DB open source database versions 7.3.0.23
> or 7.3.0.25."
> 
> (In fact, they seem to think they are testing kernel performance, not
> database performance, which strikes me as rather bizarre.  But anyway.)

That may be a terminology thing; the main SAP-DB process is called the 
"kernel," and it's more than likely that the "SAP-DB Kernel" is the sense in 
which the term is being used.

When they translate things from German, sometimes wordings change :-).
--
output = reverse("moc.enworbbc@" "enworbbc")
http://www.ntlug.org/~cbbrowne/linuxxian.html
Rules  of the  Evil Overlord  #41. "Once  my power  is secure,  I will
destroy all those pesky time-travel devices."
<http://www.eviloverlord.com/>



---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Intel drops 64-bit Itanium

[cbbrowne]

> After failing to make Itanium competitive, Intel is now downplaying
> 64-bit CPU's.  Of course, they didn't think that until Itanium failed.
> Here is the slashdot story:
>   http://slashdot.org/article.pl?sid=03/02/23/2050237&mode=nested&tid=118
> 
> Seems AMD's hammer is going to be the popular 64-bit desktop CPU.

It's really unsurprising; there was /no/ likelihood of Itanium getting
widely deployed on desktops when there would be an absolute dearth of
desktop software.

Think back: Alpha was presented in /exactly/ the same role, years ago,
and the challenges it had vis-a-vis:

 a) Need for emulation to run legacy software that can't get recompiled;
 b) Need to deploy varying binaries on the substantially varying
platforms;
 c) It's real costly to be an early adoptor of new hardware, so the
hardware is expensive stuff.

Certain sorts of "enterprise" software got deployed on Alpha, but you
never got the ordinary stuff like MS Office and such, which meant there
was no point to anyone pushing "desktop" software to Alpha.  And we
thereby had the result that Alpha became server-only.

Why should it be the slightest bit remarkable that IA-64 is revisiting
the very same marketing challenges?  

It has the very same set of technical challenges.

It may well be that by the time it /is/ time to generally deploy IA-64,
it will have become the Alpha platform.  After all, Compaq sold the
architecture to Intel, and Alpha already has a mature set of hardware
designs as well as compilers...
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/oses.html
"Everything should be built top-down, except the first time."
-- Alan Perlis

---(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] location of the configuration files

[cbbrowne]

> On 13 Feb 2003, Oliver Elphick wrote:
> 
> > What your comments strongly suggest to me is that projects like
> > PostgreSQL and pine, along with everything else, should comply with FHS;
> > then there will be no confusion because everyone will be following the
> > smae standards.  Messes arise when people ignore standards; we have all
> > seen the dreadful examples of MySQL and the Beast, haven't we?
> 
> Actually FHS says the opposite.  If the distribution installs PostgreSQL
> then the config files belong in /etc/postgresql.  If the admin does then
> they belong in /usr/local/etc/postgresql.  FHS is out of their tree.  If
> PostgreSQL or any other package is not critical to the basic operation of
> the operating system, it's config files shouldn't be polluting /etc.

I suspect you may be conflating BSD usage with Linux usage here...

The point isn't of being "critical to basic operation of the operating 
system;" it is of whether or not the software is being "package-managed" or 
not.

One of the operating principles in FHS is that "/usr/local" is an area that 
the distribution should never "pollute."  And so, a "package-managed" 
PostgreSQL installation should never touch that area.

Looking at FHS, for a moment: http://www.pathname.com/fhs/2.2/

3.7.1 Purpose
/etc contains configuration files and directories that are specific to the 
current system.

3.7.4  Indicates that 

"Host-specific configuration files for add-on application software packages 
must be installed within the directory /etc/opt/, where  is 
the name of the subtree in /opt where the static data from that package is 
stored."

3.12 indicates: /opt is reserved for the installation of add-on application 
software packages.

A package to be installed in /opt must locate its static files in a separate 
/opt/ directory tree, where  is a name that describes the 
software package.

Then comes 5.1, on /var

/var contains variable data files. This includes spool directories and files, 
administrative and logging data, and transient and temporary files.

It would make most sense, based on FHS, for PostgreSQL information to 
assortedly reside in:

- /etc/opt/postgresql or /etc/postgresql, for static config information;
- Binaries could assortedly live in /usr/bin or /opt/postgresql;
- Logs should live in /var/log or /var/log/postgresql;
- Data could assortedly live in /var/lib/postgresql, /var/opt/postgresql;
- PIDs should live in /var/lock or /var/lock/postgresql.

None of these choices should come as any spectacular shock to anyone; there 
are an assortment of sets of bigotry out there surrounding the Proper Purposes 
of /opt and /usr/local, and there's probably enough wriggle room there to 
avoid overly enraging anyone that (for instance) felt calling a directory 
"/opt" would make someone deserving of carpet bombing by B-52s.

Interestingly, the Debian install of PostgreSQL somewhat resembles this, with, 
assortedly:

/etc/postgresql
/etc/postgresql/postgresql.conf
/etc/postgresql/postmaster.conf
/etc/postgresql/pg_hba.conf
/etc/postgresql/pg_ident.conf
/etc/init.d/postgresql
/usr/share/doc/postgresql
/usr/share/man/man1/pg_ctl.1.gz
/usr/lib/postgresql
/usr/lib/postgresql/bin/postgres
/usr/lib/postgresql/bin/enable_lang
/usr/lib/postgresql/bin/initdb
/usr/lib/postgresql/bin/initlocation
/usr/lib/postgresql/bin/ipcclean
/usr/lib/postgresql/bin/pg_ctl
/usr/lib/postgresql/bin/pg_dumpall
/var/run/postgresql

(This is obviously incomplete; this just gives the flavor that there are files 
in a reasonably rational but diverse assortment of places.)

Note that the server software hides in /usr/lib/postgresql/bin; it's not stuff 
you should normally run from the command line, so, quel surprise, it is 
stashed somewhere that's unlikely to be in your $PATH.

Stashing _everything_ in /var/lib/postgres would seem a tad surprising.

Mind you, if I need to manage 4 instances on one box, I might very well 
install several instances some place custom, say /opt/postgres, or similar, 
and in that case, it's probably preferable for everything to reside clearly 
underneath that, and for my custom backup scripts to work in that area.

But if I'm managing 4 instances on one box, it should be quite evident that 
I'm going well beyond what any packaging system is likely to be prepared to 
handle.  Again, quel surprise.
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/linuxxian.html
"Of  _course_ it's the murder weapon.   Who would frame someone with a
fake?"



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] new procedural language - PL/R

[cbbrowne]

> >>Any strong feelings on whether this is necessary for a first release?
> > 
> > No.  I'm not sure you'd really need triggers written in R ever ;-)
> 
> Yeah, that's what I figured too.

Indeed.  R sounds like it might be an interesting platform from which to
do "data mining," and in that sort of context, you're almost exclusively
reading data, so the loss of triggers would be of no great importance.

What might be "nifty" would be to have some mappings that did Clever
Transformations of Queries Into Views, particularly if that allowed
harnessing the DBMS to do some of the statistical analysis behind your
back...
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www3.sympatico.ca/cbbrowne/rdbms.html
"After you've  heard two  eyewitness accounts of  an auto  accident it
makes you wonder about history." -- Bits and Pieces

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

[HACKERS] Case Studio II

[cbbrowne]

Has anyone seriously tried out this package?

It looks like a "cheaper variant on ERWin," with the merit of having
some PostgreSQL support.  

It only runs on WinTel, which is somewhat unfortunate, but I haven't
gotten the sort of diagramming I have been looking for out of AutoDoc,
so I'd be game to look at something "pricey," assuming it is useful.
--
http://cbbrowne.com/info/linux.html
Rules of the Evil Overlord #50. "My main computers will have their own
special  operating system  that will  be completely  incompatible with
standard IBM and Macintosh powerbooks."


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [mail] Re: [HACKERS] Windows Build System

[cbbrowne]

Jan Wieck wrote:
> Looking at the arguments so far, nearly everyone who questions the Win32
> port must be vehemently against the Cygwin stuff anyway. So that camp
> should be happy to see it flushed down the toilet. And the pro-Win32
> people want the native version because they are unhappy with the
> stepchild-Cygwin stuff too, so they won't care too much.

What is interesting is that the MySQL folk don't seem to be vehemently against 
it, as a look at their downloads pages indicate that they depend on Cygwin for 
the Windows port of their product.
--
output = ("cbbrowne" "@ntlug.org")
http://www.ntlug.org/~cbbrowne/lisp.html
"What did we agree about a leader??"
"We agreed we wouldn't have one."
"Good.  Now shut up and do as I say..."



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [mail] Re: [HACKERS] Windows Build System

[cbbrowne]

> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Assuming all your assumptions are right, why the hell is Oracle's and MS
> > SQL-Server's reputation that bloody good?
> 
> They have marketing departments.

... As well as sizable systems integration departments devoted to the 
platforms in question.  PostgreSQL doesn't have the latter, although the 
recent efforts make a move towards it.

> > And what about MySQL?
> 
> What about it?  Someone claimed in this thread that MySQL's Windows port
> requires Cygwin.  Is that true or not?

http://www.mysql.com/downloads/mysql-3.23.html
"Windows downloads

The Windows binaries use the Cygwin library. Source code for the version of 
Cygwin we have used is available on this page."
http://www.mysql.com/downloads/cygwin.html
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/spiritual.html
"When you have eliminated the impossible, whatever remains, however
improbable, must be the truth." -- Sir Arthur Conan Doyle (1859-1930),
English author. Sherlock Holmes, in The Sign of Four, ch. 6 (1889).
[...but see the Holmesian Fallacy, due to Bob Frankston...
<http://www.frankston.com/public/Essays/Holmesian%20Fallacy.asp>]



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [mail] Re: [HACKERS] Windows Build System

[cbbrowne]

Jeff Davis wrote:
> > What about it?  Someone claimed in this thread that MySQL's Windows port
> > requires Cygwin.  Is that true or not?
> 
> It's been a while, but I know I've installed MySQL on windows without any 
> separate step of installing Cygwin (I can't say 100% for sure that it didn't 
> install some part of Cygwin transparently to me).

That may have involved "not being sufficiently observant," because the company 
quite clearly documents Cygwin as a dependancy.
http://www.mysql.com/downloads/cygwin.html
--
output = ("aa454" "@freenet.carleton.ca")
http://www3.sympatico.ca/cbbrowne/linuxxian.html
Change is inevitable, except from a vending machine. 



---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [mail] Re: [HACKERS] Windows Build System

[cbbrowne]

Justin Clift wrote:
> For another perspective, we've been getting a few requests per day 
> through the PostgreSQL Advocacy and Marketing site's request form along 
> the lines of:
> 
> "Is there a license fee for using PostgreSQL?  We'd like to distribute 
> it with our XYZ product that needs a database."
> 
> Probably about 4 or so per day like this at present.  A lot of the 
> people sending these emails appear to have windows based products that 
> need a database, and have heard of PostgreSQL being a database that they 
> don't need to pay license fee's for.  They've kind of missed the point 
> of Open Source from the purist point of view, but it's still working for 
> them.  ;-)

If they are:
 a) not clueful enough to actually look at the license, and
 b) looking at it from the purely selfish perspective of "not having to
pay license fees,"
then are they /truly/ people where it is useful to put effort into being
helpful?

Furthermore, if their lawyers are incapable of reading the license and
explaining to them "You don't have to pay," I'd suggest the thought that
maybe they have bigger problems than you can possibly solve for them.

The great security quote of recent days is thus:
  "If you spend more on coffee than on IT security, then you will be
  hacked." -- Richard Clarke

The analagous thing might be:

"If you spend more on coffee than you do on getting proper legal advice
about software licenses, then it's just possible that you might do
something DOWNRIGHT STUPID and get yourself in a whole barrel of legal
hot water."

If these people are incapable of reading software licenses, and haven't
any competent legal counsel to to do it for them, you've got to wonder
if they are competent to sell licenses to their own software.  I
seriously doubt that they are.

Furthermore, I'm not at all sure that it is wise for you to even /try/
to give them any guidance in this, beyond giving them a URL to the
license, and saying "Have your lawyer read this."  If you start giving
them interpretations of the license, that smacks of "giving legal
advice," and bar associations tend to frown on that.
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://cbbrowne.com/info/
"Interfaces keep things tidy, but don't accelerate growth: functions
do." -- Alan Perlis

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] clock sync

[cbbrowne]

On Thu, 09 Jan 2003 08:39:33 CST, the world broke into rejoicing as
"John Liu" <[EMAIL PROTECTED]>  said:
> How do I know the clock on the machine you're
> running on will be set to the same time as the 
> clock on the database? how postgre handle this
> internal?

You'll know because you already run NTP on all your servers to make
sure that they are synchronizing times, right?

PostgreSQL doesn't include time synchronization software because NTP
does that perfectly well, just as it doesn't include a job scheduler
because cron does that perfectly well.

... And if your machines have substantially different times, different
sorts of issues will emerge depending on what you're doing.

- If the "client" sends over literal current time stamps based on what
time it thinks it is, that may differ from what time the server thinks
it is.

- If you do that, and then try looking in PostgreSQL logs, based on
the "client's" timestamps, you'll look at the wrong times, and get
confused.

- If the client passes in things that select now(), timestamps will be
returned based on when the /server/ thinks it is.  Which should leave
the database consistent, but which might confuse the client if it has
logic that processes that time, and gets deranged because now()
differs massively from what time it thinks it is.

The case where you'll get /badly/ bitten is if you're trying to do
replication with servers that have substantially differing ideas as to
what time it is.

But what you /should/ do is run NTP on all your machines, thus getting
rid of the problem.  <http://www.ntp.org/>
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www3.sympatico.ca/cbbrowne/ntp.html
Rules  of the  Evil  Overlord #30.   "All  bumbling conjurers,  clumsy
squires, no-talent  bards, and  cowardly thieves in  the land  will be
preemptively put  to death.  My foes  will surely give  up and abandon
their quest if they have no source of comic relief."
<http://www.eviloverlord.com/>

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] psql and readline

[cbbrowne]

On Thu, 09 Jan 2003 10:13:14 EST, the world broke into rejoicing as
Bruce Momjian <[EMAIL PROTECTED]>  said:
> Justin Clift wrote:
> > Bruce Momjian wrote:
> > 
> > > Let's suppose I am writing a query, and then I do \e to edit the query,
> > > and I exit the editor and return to psql.  Suppose I decide I want to
> > > reedit, so I up arrow.  I would expect to get \e, not the query I just
> > > edited, no?
> > 
> > Wouldn't it depend on how this gets implemented?
> > 
> > Maybe least negative impact approach (suggested already): If the "large 
> > command that was edited" is put in the command history before the \e, 
> > then both are available and there is no big change from "expected 
> > behaviour".
> > 
> > i.e. one up arrow get the previous \e, and a second up arrow would bring 
> > up the command that was worked upon.
> 
> Makese sense.  However, it still has the shock factor of displaying a
> huge query, which is usually what is involved when using the editor.  I
> don't feel strongly either way --- I am just pointing out the issue.

There's a surprise available in both directions.

If the previous command was "use external editor on query," then it
seems unreasonable to forcibly expand that out.  If I edited the
query, it's more than likely that I'd like to edit it again.

But I'd like to have a way to expand the query so that I /can/ see it
in full form.  It would be unfortunate for the /only/ way to get at
the query would be to \e it.

Perhaps the answer is to have some form of "\expand" directive that
replaces itself with the query's contents, or, better still, which
doesn't actually /execute/ the query, but rather pulls in the query
from outside and pushes it into the command line.  The /next/ time you
hit enter, the query will get executed.
--
output = reverse("moc.enworbbc@" "enworbbc")
http://cbbrowne.com/info/linux.html
Eagles may soar, free and proud, but weasels never get sucked into jet
engines.

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] OS/400 support?

[cbbrowne]

In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Tom Lane) 
transmitted:
> Justin Clift <[EMAIL PROTECTED]> writes:
>> We don't support OS/400 yet do we?
>
> Never heard of it.  Is it Unix-y?  Do you have one available for testing?

No, OS/400 is what replaced IBM System 34, System 36, and System 38.
(Apparently they jumped to 40, and then multiplied by 10 to suggest it
was 10x as good...)

It was based on the CMU "Hydra" project, which built an OS with a pretty
strong security kernel, with ties to the "orthogonal persistence"
notion.

By this point, they have created a POSIX-emulation environment so it can
pretend to be somewhat like a Unix, but underneath, it's a database
system for running RPG code.  As such, it kind of starts as a DBMS.

Somehow, I'm not sure that PostgreSQL-on-OS/400 is likely to be more
than a curiosity.
-- 
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/rdbms.html
If you can't see the bright side of things, polish the dark side...

---(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] [GENERAL] PostgreSQL Global Development Group

[cbbrowne]

Kevin Brown wrote:
> Devrim G?ND?Z wrote:
> > I do NOT like hearing about MySQL in this (these) list(s).
> > 
> > PostgreSQL is not in the same category with MySQL. MySQL is for
> > *dummies*, not database admins. I do not even call  it a database. I
> > have never forgotten my data loss 2,5 years ago; when I used MySQL for
> > just 2 months!!! 
> 
> I think you're on to something here, but it's obscured by the way you
> said it.
> 
> There's no question in my mind that PostgreSQL is superior in almost
> every way to MySQL.  For those of us who are technically minded, it
> boggles the mind that people would choose MySQL over PostgreSQL.  Yet
> they do.  And it's important to understand why.
> 
> Simply saying "MySQL has better marketing" isn't enough.  It's too
> simple an answer and obscures some issues that should probably be
> addressed.

I think it /is/ a significant factor, the point being that the MySQL company 
has been quite activist in pressing MySQL as "the answer," to the point to 
which there's a development strategy called "LAMP" (Linux + Apache + MySQL + 
(Perl|Python|PHP)).

> People use MySQL because it's very easy to set up, relatively easy to
> maintain (when something doesn't go wrong, that is), is very well
> documented and supported, and is initially adequate for the task they
> have in mind (that the task may change significantly such that MySQL
> is no longer adequate is something only those with experience will
> consider).

... And the consistent marketing pressure that in essence claims:

 - It's easier to use than any alternative;
 - It's much faster than any other DBMS;
 - It's plenty powerful and robust enough.

As near as I can tell, /none/ of these things are true outside of very 
carefully selected application domains.  But the claims have been presented 
enough times that people actually believe them to be true.

> PostgreSQL has come a long way and, with the exception of a few minor
> things (the need to VACUUM, for instance.  The current version makes
> the VACUUM requirement almost a non-issue as regards performance and
> availability, but it really should be something that the database
> takes care of itself), is equivalent to MySQL in the above things
> except for documentation and support.

I would point to a third thing:  Tools to support "hands-off administration."  
My web hosting provider has a set of tools to let me administer various 
aspects of my site complete with "pretty GUI" that covers:
 - Configuring email accounts, including mailing lists, Spam Assassin, and 
such;
 - Configuring subdomains;
 - Managing files/directories, doing backups;
 - Apache configuration;
 - Cron jobs;
 - A couple of "shopping cart" systems;
 - A "chat room system;"
 - Last, but certainly not least, the ability to manage MySQL databases.

There is no "canned" equivalent for PostgreSQL, which means that ISPs that 
don't have people with DBMS expertise will be inclined to prefer MySQL.  It's 
a better choice for them.

> MySQL's documentation is very, very good.  My experience with it is
> that it's possible, and relatively easy, to find information about
> almost anything you might need to know.
> 
> PostgreSQL's documentation is good, but not quite as good as MySQL's.
> It's not quite as complete.  For instance, I didn't find any
> documentation at all in the User's Guide or Administrator's Guide on
> creating tables (if I missed it, then that might illustrate that the
> documentation needs to be organized slightly differently).  I did find
> a little in the tutorial (about the amount that you'd want in a
> tutorial), but to find out more I had to go to the SQL statement
> reference (in my case I was looking for the means by which one could
> create a constraint on a column during table creation time).
> 
> The reason this is important is that the documentation is *the* way
> people are going to learn the database.  If it's too sparse or too
> disorganized, people who don't have a lot of time to spend searching
> through the documentation for something may well decide that a
> different product (such as MySQL) would suit their needs better.
> 
> The documentation for PostgreSQL improves all the time, largely in
> response to comments such as this one, and that's a very good thing.
> My purpose in bringing this up is to show you what PostgreSQL is up
> against in terms of widespread adoption.

That's probably pretty fair.  I'm using the word "fair" advisedly, too.

If someone objects, saying that PostgreSQL docs /are/ good, keep in mind that 
new users are not mandated to be "fair" about this.  If they have trouble 
finding what they were looking for, they couldn't care less that you think the 
docs are pretty good: /they/ didn't find what /they/ were looking for, and 
that's all they care about.

> > If we want to "sell" PostgreSQL, we should talk about, maybe, Oracle.
> > I have never took care of MySQL said. I just know that I'm running
> > PostgreSQL since 2,5 years and I only s

Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces

[cbbrowne]

> > > It isn't, but those working on -advocacy were asked to help come up with
> a
> > > stronger release *announcement* then we've had in the past ...
> >
> > Consider that a failed experiment.  PostgreSQL is driven by the
> > development group and, to some extent, by the existing user base.  The
> > last thing we need is a marketing department in that mix.
> 
> Ummm...I disagree.  Lack of marketing is one of Postgres's major problems.
> Particularly when you compare against similar efforts from MySQL, Oracle,
> etc.

Yes, indeed.

The _prime_ reason for the fact that MySQL is the "M" in "LAMP" is that there 
is a steady, intent set of efforts going into marketing the "M."  People think 
that MySQL is faster, easier to use and "more standard" than its alternatives, 
and that is certainly the result of marketing.

The /real/ technical merit of MySQL has been that there are some integrated 
tools for ISPs like CPANEL that make it easy for ISPs that don't know 
/anything/ about DBMSes to provide MySQL for their customers.  CPANEL doesn't 
support PostgreSQL, and historically, it has been somewhat more difficult to 
support large numbers of PostgreSQL instances on a web server.  Some of that 
has changed, though CPANEL /still/ doesn't support PostgreSQL.

If any of you consider these "technical" issues to be small and petty, I'm 
afraid I don't /care/.  More importantly, the hundreds of ISPs licensing 
CPANEL don't care.  /They/ are the ones that would need convincing, and I 
don't think there's any real route to convince them that they should be 
pounding down CPANEL's door asking for a PostgreSQL front end and to convince 
them that they have to tell their customers:

  "We sold you MySQL, telling you it was good for you to use.  We were
   wrong, and our new story is that you should convert your databases over
   to use PostgreSQL."

Anyone consider that a likely scenario?  Anyone?

It's fair to say that PostgreSQL doesn't need the likes of the "Database 
HOWTO" that gives a sales job that's so blindly enthusiastic as to be, well, 
blind.

But an organization that has /no/ "marketing department" is at a severe 
disadvantage, like it or not.

It is unfortunate that it is almost impossible to have a marketing group 
without there being some wilful blinders involved; it's vital for there to be 
some technical involvement in the marketing group to pop whatever bubbles they 
grow that are woefully wrong.  But even if it operates with some occasional 
lack of /real/ vision, it's necessary to have a marketing group...
--
(reverse (concatenate 'string "moc.enworbbc@" "sirhc"))
http://cbbrowne.com/info/advocacy.html
Rules of the  Evil Overlord #106. "If my  supreme command center comes
under attack, I will immediately  flee to safety in my prepared escape
pod and  direct the  defenses from  there. I will  not wait  until the
troops break into my inner sanctum to attempt this."




---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Shrinkwrap Windows Product, any issues? Anyone?

[cbbrowne]

> I've looked long and hard and can't find any license issues. Does anyone 
> know of any that I may have missed? As far as I can see, as long as I 
> maintain GPL restrictions, I should be fine.

PostgreSQL isn't licensed under the GPL, so it sounds to me as though you're 
confused about the licensing issues.
--
(concatenate 'string "cbbrowne" "@cbbrowne.com")
http://www3.sympatico.ca/cbbrowne/lsf.html
"My mom said she learned how to swim. Someone took her out in the lake
and threw  her off  the boat. That's  how she  learned how to  swim. I
said, 'Mom, they  weren't trying to teach you how  to swim.' " 
-- Paula Poundstone



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] RC1?

[cbbrowne]

On Wed, 13 Nov 2002 10:06:15 EST, the world broke into rejoicing as
Tom Lane <[EMAIL PROTECTED]>  said:
> "Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> > Why use awk for this at all ? and not:
> > echo "\\set ECHO all"
> 
> I think Bruce is worried about portability; some versions of echo might
> do something weird with the backslash.  OTOH, it's not obvious to me
> that awk is better on that score.  Bruce?

The problem is that the regress script isn't pointing to the version of
awk that was picked up in the autoconf phase.

(More detailed comments forwarded directly :-).)

The "real deal" on what happens on Solaris is thus, from the awk FAQ,
where Patrick McPhee writes:

> SunOS includes three versions of awk. /usr/bin/awk is the old
> (pre-1989) version. /usr/bin/nawk is the new awk which appeared in
> 1989, and /usr/xpg4/bin/awk is supposed to conform to the single unix
> specification.  No one knows why Sun continues to ship old awk.

I would be /very/ inclined to trust Patrick's wisdom on this.

So long as we fix up the regression script to grab the "nawk" that
we expect to work, that's probably nicer than figuring out which
echo parameters are needed...
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://cbbrowne.com/info/wp.html
The first cup of coffee recapitulates phylogeny.

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] Hot Backup

[cbbrowne]

The world rejoiced as [EMAIL PROTECTED] (Andrew Sullivan) wrote:
> Having undertaken the exercise, I really can say that it is a little
> strange to think about what would happen to data I am in charge of in
> case a fairly large US centre were completely blown off the map.  But
> with a little careful planning, you actually _can_ think about that,
> and provide strong assurances that things won't get lost.  But it
> doesn't pay to call such questions "silly", because they are
> questions that people will demand answers to before they entrust you
> with their millions of dollars of data.  

I was associated with one data center that has the whole
"barbed-wire-fences, 40-foot-underground-bunker, retina-scanning"
thing; they apparently /did/ do analysis based on the site being a
potential target for nuclear attack.

Realistically, two scenarios are much more realistic:

 a) The site resides in a significant tornado zone where towns
occasionally get scraped off the map;

 b) The site isn't far from a small but busy airport, and they did
consciously consider the possibility of aircraft crashing into the
building.  Presumably by accident, not by design; the company owns
quite a number of jet aircraft, so that vulnerabilities involving
misuse of aircraft would rapidly "fly" to mind...  (Painfully
and vastly moreso since 9/11, of course :-(.)

When doing risk analysis, it is certainly necessary to consider these
sorts of (admittedly paranoid) scenarios.  

It's a bit fun, in a way; you get to look for some pretty odd-ball
situations; the "server room being overrun by Mongol Hordes."  That
particular one isn't too likely, of course :-).
-- 
(reverse (concatenate 'string "moc.enworbbc@" "sirhc"))
http://www.ntlug.org/~cbbrowne/advocacy.html
"I've discovered  that P=NP, but the  proof is too long  to fit within
the confines of this signature..."

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Anyone want to assist with the translation of the

[cbbrowne]

Justin wrote:
> Hi Michael,
> Michael Paesold wrote:
>  
> > Hi Justin,
> > I am from Austria, and I would like to help. I could provide a German
> > translation. The Babelfish's translation is really funny. Machine
> > translation is readable, but it is no advocacy. ;-) I do not really nead an
> > interface, but just tell me in what way you want the texts.
> 
> Cool.  Could you deal with an OpenOffice Calc or M$ Excel file having
> the lines of English text in one column, and doing the German
> translation into a second column?

Isn't this, um, the sort of thing you might want to put into, um, a, um, 
database?
--
(concatenate 'string "aa454" "@freenet.carleton.ca")
http://cbbrowne.com/info/internet.html
"you  can   obvioulsy understand what  i'm  saying.  you're just being
pendantic." -- [EMAIL PROTECTED]



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Inheritance

[cbbrowne]

Oops! [EMAIL PROTECTED] (Greg Copeland) was seen spray-painting on a wall:
> --=-eu74lKXry3SVx8eZ/qBD
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
> On Fri, 2002-09-06 at 08:57, [EMAIL PROTECTED] wrote:
>> > On Fri, 2002-09-06 at 07:37, Curt Sampson wrote:
>> > > On 5 Sep 2002, Hannu Krosing wrote:
>> > To elaborate on Gregs example if you have table GOODS and under it a
>> > table CAMPAIGN_GOODS then you may place a general overridable constraint
>> > valid_prices on GOODS which checks that you dont sell cheaper than you
>> > bought, but you still want sell CAMPAIGN_GOODS under aquiring price, so
>> > you override the constraint for CAMPAIGN_GOODS.

>> What that tells me is that the constraint, valid_prices, shouldn't
>> have been on GOODS in the first place.  If it is not a legitimate
>> constraint for the children, then it is not a legitimate constraint
>> for the parent.

> I don't agree with you on that point.  This concept is common to
> many OO-implementations.  Unless you can come up with a powerful
> argument as to why our "to-be" picture should never do this, I'm
> less than convinced.

If the plan is for table CAMPAIGN_GOODS to virtually be a view on GOODS,
then I'd say it _is_ necessary.

>> In human inheritance, if you marry someone with "funny coloured skin," yo=
> u=20
>> don't get to choose that your children won't have "funny coloured skin."=
> =20=20
>> That's a pretty forcible "constraint."  :-).
>>=20

Is there something broken with your mailer?  It's reformatting quotes
rather horribly...

> Fine, but that only works for YOUR specific example.  In that
> example, the color constraint should be non-virtual, meaning, the
> child should not be able to change it.  On the other hand, if I
> replace "human" with "metal product", hopefully I won't be stuck
> with gun metal gray for every derived product.  Hopefully, somewhere
> along the lines, I'll be able to override the parent's color
> constraint.

That happens by _adding_ an additional characteristic, presumably that
of "what kind of paint the metal is covered with."  That doesn't
override the fundamental constraint that if it's a metal product,
there _will_ be metallic properties.

If you decide to add in some "non-metallic" products, then it would be
_silly_ to have them inherit all their characteristics from
"METAL_PRODUCTS;" they should head back up the class hierarchy and
inherit their basic characteristics from the _appropriate_ parent.

Reality, with the "GOODS/CAMPAIGN_GOODS" example, is that GOODS isn't
the appropriate parent class for CAMPAIGN_GOODS.  Both should be
inheriting the common characteristics from some common ancestor.  If
that is done, then there's nothing to "override."

>> > Or maybe it is better to just make the check function should be
>> > dynamically dispatched, so the constraint will always hold, it just can
>> > mean different things for different types.
>>=20
>> Or maybe if someone is doing an Object Oriented design, and making extens=
> ive=20
>> use of inheritance, they'll need to apply constraints in a manner that al=
> low=20
>> them to be properly inherited.

> The problem with that assumption is that there is normally nothing
> wrong with having seemingly mutually exclusive sets of *business
> rules* for a parent and child.

If the rules are totally different, it begs the question of why they
_should_ be considered to be related in a "parent/child" relationship.

It may well be that they _aren't_ related as "parent/child."  They may
merely be "cousins," sharing some common ancestors.
-- 
(concatenate 'string "chris" "@cbbrowne.com")
http://cbbrowne.com/info/spreadsheets.html
"Note that if I can get you  to `su and say' something just by asking,
you have a very serious security problem on your system and you should
look into it."  -- Paul Vixie, vixie-cron 3.0.1 installation notes

---(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

[cbbrowne]

> On Fri, 2002-09-06 at 07:37, Curt Sampson wrote:
> > On 5 Sep 2002, Hannu Krosing wrote:
> > 
> > > 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
> > 
> > This I very much disagree with.
> > 
> > In most object-oriented languages (Eiffel being a notable exception, IIRC),
> > you can't specify constraints on objects. But in a relational database,
> > you can specify constraints on tables, and it should *never* *ever* be
> > possible to violate those constraints, or the constraints are pointless.
> 
> That's not how real world (which data is supposed to model) operates ;)
> 
> As Greg already pointed out, there are two kinds of constraints -
> database integrity constraints (foreign key, unique, not null, check),
> which should never be overridden and business-rule constraints which
> should be overridable in child tables.
> 
> one can argue that the latter are not constraints at all, but they sure
> look like constraints to me ;)
> 
> To elaborate on Gregs example if you have table GOODS and under it a
> table CAMPAIGN_GOODS then you may place a general overridable constraint
> valid_prices on GOODS which checks that you dont sell cheaper than you
> bought, but you still want sell CAMPAIGN_GOODS under aquiring price, so
> you override the constraint for CAMPAIGN_GOODS.

What that tells me is that the constraint, valid_prices, shouldn't have been 
on GOODS in the first place.  If it is not a legitimate constraint for the 
children, then it is not a legitimate constraint for the parent.

In human inheritance, if you marry someone with "funny coloured skin," you 
don't get to choose that your children won't have "funny coloured skin."  
That's a pretty forcible "constraint."  :-).

For the GOODS situation, the constraint ought not to be on GOODS in the first 
place.  There ought to be a table ORDINARY_GOODS, or some such thing, to which 
the constraint applies, and from which CAMPAIGN_GOODS will _not_ be inheriting.

> > So if I have a constraint that says, "no rows appearing in this
> > table will ever violate constraint X," and then you go and create
> > a way of inserting rows into that table that violate that constraint,
> > I think you've just made the database into a non-relational database.
> 
> SQL standard constraints should be non-overridable. I still think that
> Constraint triggers should be overridable/dynamic. 
> 
> Or maybe it is better to just make the check function should be
> dynamically dispatched, so the constraint will always hold, it just can
> mean different things for different types.

Or maybe if someone is doing an Object Oriented design, and making extensive 
use of inheritance, they'll need to apply constraints in a manner that allow 
them to be properly inherited.
--
(concatenate 'string "aa454" "@freenet.carleton.ca")
http://cbbrowne.com/info/
If a cow laughed, would milk come out its nose? 



---(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] HISTORY updated, 7.3 branded

[cbbrowne]

> Shridhar Daithankar dijo: 
> 
> > On 4 Sep 2002 at 3:24, Bruce Momjian wrote:
> > 
> > > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
> > 
> > Some minor stuff,
> 
> In the schema changes description:
> 
> "Schemas allow users to create objects in their own namespace
> so two people can have the same table with the same name."

> Shouldn't it read "so two people can have tables with the same name"
> ?  My point is that the tables are not the same, they just have the
> same name.

How about this for a wording:

 "Schemas allow users or applications to have their own namespaces in
 which to create objects.  

 A typical application of this is to allow creation of tables that
 _appear_ to have the same name.  For instance, if some GNOME
 applications were using PostgreSQL to store their configuration, a
 "GNUMERIC" namespace might have a table PREFERENCES to store
 preferences for that application, while a "POWERSHELL" namespace
 would allow _that_ application to store configuration in a
 PREFERENCES table that is quite distinct from the "GNUMERIC" one.

 The "true" table names may be GNUMERIC.PREFERENCES and
 POWERSHELL.PREFERENCES, but by using Schemas, applications do not
 need to be speckled with gratuitious added prefixes of GNUMERIC or
 POWERSHELL."

Note that I'm pointing at "applications" as the primary purpose for
this, as opposed to "users."

In the long run, are not applications more likely to be the driving
force encouraging the use of schemas?
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/unix.html
"The   most  precisely-explained   and   voluminously-documented  user
interface "rule" can and will  be shot to pieces with the introduction
of a single new priority consideration." -- Michael Peck





---(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] How To Make Things Appear More Dramatic

[cbbrowne]

> An alarmist style when posting a serious error is a good idea.  "Hey
> guys, I found a possible problem..."  Does not seem to generate the
> needed level of excitement.  DOS attacks means that business stops.  I
> think that should generate a furrowed brow, to say the least.

Obviously people have forgotten past history.  The Symbolics guys had
_great_ techniques for this that were well documented:

It is considered artful to append many messages on a subject, leaving
only the most inflammatory lines from each, and reply to all in one
swift blow.  The choice of lines to support your argument can make or
break your case.
-- from the Symbolics Guidelines for Sending Mail
%
State opinions in the syntax of fact: "...as well as the bug in LMFS
where you have to expunge directories to get rid of files."
-- from the Symbolics Guidelines for Sending Mail
%
People can be set wondering by loading obscure personal patchable
systems, and sending bug reports.  Who would not stop and wonder upon
seeing "Experimental TD80-TAPE 1.17, MegaDeath 2.5..."?  The same for
provocatively-named functions and variables in stack traces.
-- from the Symbolics Guidelines for Sending Mail
%
Know the list of "large, chronic problems".  If there is any problem
with the window system, blame it on the activity system.  Any lack of
user functionality should be attributed to the lack of a command
processor.  A suprisingly large number of people will believe that you
have thought in depth about the issue to which you are alluding when you
do.
-- from the Symbolics Guidelines for Sending Mail
%
Know how to blow any problem up into insolubility.  Know how to use the
phrase "The new ~A system" to insult its argument, e.g., "I guess this
destructuring LET thing is fixed in the new Lisp system", or better yet,
PROLOG.
-- from the Symbolics Guidelines for Sending Mail
%
Never hit someone head on, always sideswipe.  Never say, "Foo's last
patch was brain-damaged", but rather, "While fixing the miscellaneous
bugs in 243.xyz [foo's patch], I found"
-- from the Symbolics Guidelines for Sending Mail
%
Idiosyncratic indentations, double-spacing, capitalization, etc., while
stamps of individuality, leave one an easy target for parody.
-- from the Symbolics Guidelines for Sending Mail
%
Strong language gets results.  "The  reloader is completely broken  in
242" will open  a lot more eyes than  "The reloader doesn't load files
with intermixed spaces, asterisks,  and <'s in   their names that  are
bigger than 64K".  You can always say the latter in a later paragraph.
-- from the Symbolics Guidelines for Sending Mail
%
Including a destination in the CC list that will cause the recipients'
mailer to blow out is a good way to stifle dissent.
-- from the Symbolics Guidelines for Sending Mail
%
When  replying, it  is  often possible  to cleverly edit  the original
message in such a way  as to subtly alter  its meaning or tone to your
advantage while  appearing that you are  taking pains  to preserve the
author's intent.   As a   bonus,   it will   seem that your   superior
intellect is cutting through all the excess verbiage to the very heart
of the matter.  -- from the Symbolics Guidelines for Sending Mail
%
Referring to undocumented  private communications allows one to  claim
virtually anything: "we discussed this idea in  our working group last
year, and concluded that it was totally brain-damaged".
-- from the Symbolics Guidelines for Sending Mail
%
Points  are awarded for   getting   the last   word in.   Drawing  the
conversation out so long  that the original  message disappears due to
being indented off the right hand edge of the screen is  one way to do
this.  Another is to imply that  anyone replying further is a hopeless
cretin and is wasting everyone's valuable time.
-- from the Symbolics Guidelines for Sending Mail
%
Keeping a secret "Hall Of Flame" file  of people's mail indiscretions,
or copying messages to  private mailing lists for subsequent derision,
is good  fun  and also  a worthwhile  investment  in case  you need to
blackmail  the senders later.   -- from  the Symbolics Guidelines  for
Sending Mail
%
Users should cultivate an ability to make the simplest molehill into a
mountain   by   finding   controversial interpretations   of innocuous
sounding statements that the sender never intended or imagined.
-- from the Symbolics Guidelines for Sending Mail
%
Obversely, a lot of  verbal mileage can  also be gotten by sending out
incomprehensible, cryptic,  confusing or unintelligible  messages, and
then iteratively  "correcting"  the "mistaken  interpretations" in the
replys.  -- from the Symbolics Guidelines for Sending Mail
%
Trivialize   a user's bug report  by  pointing out that   it was fixed
independently long ago in a system that hasn't been released yet.
-- from the Symbolics Guidelines for Sending Mail
%
Send  messages calling for fonts  not  available to the  recipient(s).
This can (in the case of Zmail) totally disable the 

Re: [HACKERS] Documentation DTD

[cbbrowne]

> Rod Taylor writes:
> 
> > Anyone mind if we bump the DTD version to Docbook 4.2?
> 
> Not sure if we should do this now.  We're approaching the time where
> people should be writing documentation, not having to refiddle their
> carefully crafted DocBook installations.  We're not going to realize any
> immediate benefits anyway.

Indeed.

> > What it buys is a number of useful tags, SVGs and probably more
> > importantly for the future, xsl and fop support which will probably be
> > important in the future.  OpenJade hasn't had a new release in quite a
> > long time -- not to say work isn't needed.
> 
> The last release was in January.
> 
> > Yes, after updating docs to the newer DTD I intend to make them XML
> > compliant to ensure they work with v5 of docbook in the future.
> 
> Ah, an XML vs. SGML debate.  I look forward to it.

Please no!

If and when it becomes forcibly preferable to use XML, there's a
tool called sgml2xml that is part of the "sp" package (which includes nsgmls 
and sgmlnorm) that does a Perfectly Good Job of this.  Totally automated.

Possible exception: sgml2xml capitalizes all the tags, and it looks like the 
XML DTD wants MixedCaseTagging, which is a rather irritating thing about XML; 
in any case, that's something that should be fixed up in one fell swoop in a 
"normalize it all and make it into XML" process LATER.

It would make sense to fix use of any deprecated elements, but "fixing" any 
XML aspects of it now is pretty much a senseless exercise.
--
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/emacs.html
"Computers in the future may weigh no more than 1.5 tons".  -- POPULAR
MECHANICS magazine forecasting the "relentless march of science" 1955



---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Standard replication interface?

[cbbrowne]

> --=-QQHYShMlxI2BY71i6NiO
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
> 
> > As I said -- I don't really see the need for a bunch of replication
> > implementations, and therefore I don't see the need for a generic API
> > to make the whole mess (slightly) more manageable.
> 
> I see.  So the intension of the core developers is to have one and only
> one replication solution?

If the various "solutions" may be folded down into a smaller set of programs, 
perhaps, ultimately, into _one_ program, that would surely be easier to 
manage, in the codebase, than having five or six such programs.

If one program can do the job that needs to be done, and it has not been 
_clearly_ established that that is _not_ possible, then I'd think it rather 
silly to have a bunch of "replication solutions" that need to be updated any 
time a relevant change goes into the database engine.

I'd be surprised if, in the end, there truly _needed_ to be more than about 
two approaches.

Should the team plan to _have_ a mess?  I'd think not.
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://cbbrowne.com/info/linuxdistributions.html
"We don't understand the  software, and sometimes we don't  understand
the hardware, but we can *see* the blinking lights!"  -- Unknown



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

[HACKERS] Table inheritance versus views

[cbbrowne]

On 29 Jul 2002 18:27:40 MDT, the world broke into rejoicing as
Stephen Deasey <[EMAIL PROTECTED]>  said:
> Curt Sampson wrote:
>> I'm still waiting to find out just what advantage table inheritance
>> offers. I've asked a couple of times here, and nobody has even
>> started to come up with anything.

> Table inheritance offers data model extensibility.  New (derived) tables
> can be added to the system, and will work with existing code that
> operates on the base tables, without having to hack up all the code.

But it kind of begs the question of why you're creating the new table in
the first place.

The new table certainly _won't_ work with existing code, at least from
the perspective that the existing code doesn't _refer_ to that table.

The same is not true for views; if you create a new view on a table, the
existing code that refers to the table in either "raw" form or in other
views already exist will certainly continue to work.

> Inherited indexes etc. would be nice, but it's the inability to have
> referential integrity against a base table that picks up child table
> rows that makes the current implementation useles.

Views will certainly inherit indices, and continue to maintain
referential integrity against the "base" table.

> I would rather see it fixed than junked, and better yet extended.  It
> would be incredibly useful in real-world projects with complex data
> models like OpenACS.

Have they found views to be an unacceptable alternative?

I just don't see that there's _all_ that much about table inheritance
that is really fundamentally wonderful.

The "incredibly useful" thing, it seems to me, would be to provide tools
that make it less necessary to create additional tables.  To be sure,
views do that.

I'm not quite sure what INHERITS buys us that we don't get from
  SELECT * into new_table from old_table

INHERITS may automagically draw in some contraints that have been
specifically tied to old_table that wouldn't be drawn by "SELECT * INTO
NEW_TABLE"; the latter _will_ inherit anything that is tied to the
types.

I'd _much_ rather have five views on one table than five tables.
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://cbbrowne.com/info/spreadsheets.html
"Everything should  be made as  simple as possible, but  not simpler."
-- Albert Einstein

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

[HACKERS] Third Manifesto

[cbbrowne]

> On Fri, 2002-08-02 at 08:55, Curt Sampson wrote:
> > On Fri, 2 Aug 2002, Marc G. Fournier wrote:
> > 
> > > Isn't inheritance kinda one of those things that is required in order to
> > > be consider ourselves ORBDMS, which we do classify our selves as being?
> > 
> > Well, it depends on what you call an ORDBMS. By the standards of
> > Date and Darwen in _The Third Manifesto_,
> 
> Is _The Third Manifesto_ available online ?

The full book is not.

An earlier version of the work is available as: http://www.acm.org/sigmod/recor
d/issues/9503/manifesto.ps

It's actually an easier read than the full book.
--
(concatenate 'string "cbbrowne" "@cbbrowne.com")
http://www3.sympatico.ca/cbbrowne/finances.html
"very few people approach me in real life and insist on proving they
are drooling idiots."  -- Erik Naggum, comp.lang.lisp



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?

[cbbrowne]

> 
> Just a long standing curiosity?
> 
> For most web sites MySQL seems to work fine, but overall PostgreSQL offers 
> more capabilites so why build upon a limited base such as MySQL?
> 
> Does anyone here have any idea as to why so many people select MySQL when 
> both systems are open sourced?

Three likely effects:

a) ISP management toolsets include management tools for MySQL, and not 
PostgreSQL.

(CPanel is an example of such a toolset.)

b) Apparently the permissions model for PostgreSQL used to discourage its use 
in shared hosting environments.  (Ask Neil Conway more about this.)

c) There was corporate sponsorship of MySQL, and they probably spent money 
marketing it in the ISP web hosting market.

d) MySQL is GPL-licensed, and some people consider that very important.  (And 
are too stupid to grasp that they like XFree86, which _isn't_ licensed under 
the GPL...  Of course, this is d), and I said "three" likely effects...)

e) Inertia.  MySQL got more popular way back when; the reasons may no longer 
apply, but nobody is going to move to PostgreSQL without _compelling_ reason, 
and you'll have to show something _really compelling_.
--
(concatenate 'string "cbbrowne" "@acm.org")
http://cbbrowne.com/info/advocacy.html
FLORIDA: Where your vote counts and counts and counts.



---(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] Postgres idea list

[cbbrowne]

On 26 Jun 2002 14:36:15 EDT, the world broke into rejoicing as
Dave Cramer <[EMAIL PROTECTED]>  said:
> Josh,
> 
> 1) There is an open source implementation of java
> 2) The jdbc driver is much better than it was recently we have made lots
> of improvements, and it won't affect jpgadmin anyway. I actually think
> writing the admin tool in java will make the driver better.
> 3) Don't see this as a big issue we aren't writing something esoteric
> here.

There are "free software" implementations of Java compilers and of Java
Virtual Machines.

Are there suitable "free software" implementations of _all_ the
libraries that you will be needing to construct the admin tool?  

In particular, can you direct us to a free software implementation of
Swing?

I doubt that you can, and _that_ is the characteristic problem with
Java.  The language is "free enough," but the libraries you will want to
use aren't...
--
(concatenate 'string "chris" "@cbbrowne.com")
http://www3.sympatico.ca/cbbrowne/spreadsheets.html
HAKMEM ITEM 163 (Sussman):
To exchange two variables in LISP without using a third variable:
(SETQ X (PROG2 0 Y (SETQ Y X))) 



---(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] Postgres idea list

[cbbrowne]

On Wed, 26 Jun 2002 11:35:07 PDT, the world broke into rejoicing as
Josh Berkus <[EMAIL PROTECTED]>  said:
> > What do you see as the drawbacks with java, and how can they be
> > circumvented?
> 
> 1. Java is not Open Source.  It's an open standard, but not OS.

The problem is not with the language; it is with the layered libraries
on top.

It's reasonably usable as a server side language; the _real_ serious
problems come in if you want to build a GUIed application, when your
choice is between:

 a) A really klunky AWT UI that will be unacceptable to all, and

 b) A SWING UI that makes your application critically dependent on
non-"open source" software.

The old Java 1.01 stuff is fairly successfully "freely usable," but
that's not what anyone wants to develop with.  They want the cool new
J2EE stuff, and it takes some serious research to figure out that you
aren't going to be doing that with 'free software,' despite the
existence of stuff like JBoss.  You still need components that are
Definitely Not Free.

The answer is that someone has to implement a complete set of
replacements for the SunSoft components under free licenses.  That
"circumvention" is a distinctly non-trivial task.

> 2. I understand that there are some serious limitations to the current
> Postgres JDBC drivers.  I have not used them, so I'm reporting rumor,
> here.

I've not run into problems with them, but maybe my use hasn't been
extensive enough :-).
--
(concatenate 'string "cbbrowne" "@acm.org")
http://cbbrowne.com/info/rdbms.html
"Remember folks.  Street lights timed for 35 mph are also timed for 70
mph."  -- Jim Samuels



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] A fairly obvious optimization?

[cbbrowne]

On Sun, 23 Jun 2002 17:16:09 EDT, the world broke into rejoicing as
Bruce Momjian <[EMAIL PROTECTED]>  said:
> FAQ updated in section 4.8: My queries are slow or don't make use of the
> indexes. Why?
> 
> is returned.  In fact, though MAX() and MIN() don't use indexes,   
> it is possible to retrieve such values using an index with ORDER BY
> and LIMIT:
> 
> SELECT col
> FROM tab
> ORDER BY col
> LIMIT 1
> 

This sounds like the sort of thing that would be really nice to be able
to automate into the query optimizer...
--
(reverse (concatenate 'string "moc.enworbbc@" "sirhc"))
http://www3.sympatico.ca/cbbrowne/spreadsheets.html
"I decry the current  tendency to seek  patents on algorithms.   There
are better ways to  earn a living  than to  prevent other  people from
making use of one's contributions to computer science."
-- D. E. Knuth



---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Alternatives to SQL ...

[cbbrowne]

The world rejoiced as [EMAIL PROTECTED] (Martijn van Oosterhout) wrote:
> On Fri, May 24, 2002 at 12:43:36PM -0500, Gunther Schadow wrote:
>> - Sending a parse tree in XML for processing by the optimizer.
>>This circumvents the SQL language and avoids the kinds of
>>syntactic ideosyncrasies of SQL (e.g., where you put commas.)
>>This is fairly trivial, but of course the question is, would it
>>be worth it?
X-Mailer: mh-e 6.1; nmh 1.0.4+dev; Emacs 21.4

> I don't know if you can design something in XML that is expressive
> and simple enough to compete with SQL. SQL is a simple language, why
> replace it with something unless it is demonstrably better.

SQL is good at providing "linear" queries; queries that indicate some
"linear" relationship between elements.

It is not so good at representing hierarchical relationships, which is
what XML is about.

The SQL: 
   SELECT FIELDS FROM TABLE
provides you with a linear list.

SQL isn't _nearly_ as nice at representing things that are naturally
expressed as trees.  It's pretty easy to have a DB schema where you
essentially have to submit an SQL query for every level of the tree.

And I am not ignoring JOIN here; that adds _some_ ability to join
together levels of trees, but not an unlimited ability.

The XML model fundamentally involves a hierarchy, and the 'query
method' involves passing in a function that reshapes that hierarchy.
I think there would be considerable value to that.

It certainly needs to be thought about before it is implemented, but
it's worth thinking about, to be sure.
-- 
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/multiplexor.html
"It  is easier to move a  problem around  (for  example, by moving the
problem to a different part  of the overall network architecture) than
it is to solve it."  -- RFC 1925

---(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] Redhat 7.3 time manipulation bug

[cbbrowne]

> > > The last phase could be extending the API to allow multiple simultaneous
> > > time zones, detection of bad time zones, etc etc. This would involve API
> > > changes or extensions, and breaks compatibility with system-supplied
> > > infrastructure.
> > One thing that wasn't clear to me, but could use investigation: if so
> > many systems are using the same underlying timezone database info, maybe
> > there is some commonality at a level below the ISO mktime/tzset/etc API.
> > If we could make use of the system-provided TZ database at a lower level
> > while still using our own APIs not tied to time_t, it'd answer the issue
> > of compatibility with the surrounding system.  (Which is a real issue,
> > I agree --- we should be able to accept the system's standard TZ setting
> > if possible.)

> The fundamental problem (which of course can have a fundamental
> solution ;) is that a time zone database built with a 32-bit time_t
> will have time zone info through 2038 only (it is a binary file with
> 32-bit time fields -- almost certainly anyway). So if we have an
> extended time zone infrastructure using something different for time_t
> we would need to handle the case of reading non-extended time zones
> databases, which puts us back to having limitations.

Ah, but the database in question _doesn't_ consist of 32 bit time_t
values.

It consists of things like:

# @(#)zone.tab  1.26
#
# TZ zone descriptions
#
# From Paul Eggert <[EMAIL PROTECTED]> (1996-08-05):
#
# This file contains a table with the following columns:
# 1.  ISO 3166 2-character country code.  See the file `iso3166.tab'.
# 2.  Latitude and longitude of the zone's principal location
# in ISO 6709 sign-degrees-minutes-seconds format,
# either +-DDMM+-DDDMM or +-DDMMSS+-DDDMMSS,
# first latitude (+ is north), then longitude (+ is east).
# 3.  Zone name used in value of TZ environment variable.
# 4.  Comments; present if and only if the country has multiple rows.
#
# Columns are separated by a single tab.
# The table is sorted first by country, then an order within the country that
# (1) makes some geographical sense, and
# (2) puts the most populous zones first, where that does not contradict (1).
#
# Lines beginning with `#' are comments.
#
#country-
#code   coordinates TZ  comments
AD  +4230+00131 Europe/Andorra
AE  +2518+05518 Asia/Dubai
AF  +3431+06912 Asia/Kabul
AG  +1703-06148 America/Antigua
AI  +1812-06304 America/Anguilla
AL  +4120+01950 Europe/Tirane
AM  +4011+04430 Asia/Yerevan
AN  +1211-06900 America/Curacao
AO  -0848+01314 Africa/Luanda

Then a "leapseconds" table, looking like:
# The correction (+ or -) is made at the given time, so lines
# will typically look like:
#   LeapYEARMON DAY 23:59:60+   R/S
# or
#   LeapYEARMON DAY 23:59:59-   R/S

# If the leapsecond is Rolling (R) the given time is local time
# If the leapsecond is Stationary (S) the given time is UTC

# Leap  YEARMONTH   DAY HH:MM:SSCORRR/S
Leap1972Jun 30  23:59:60+   S
Leap1972Dec 31  23:59:60+   S
Leap1973Dec 31  23:59:60+   S
Leap1974Dec 31  23:59:60+   S
Leap1975Dec 31  23:59:60+   S
Leap1976Dec 31  23:59:60+   S

And then a set of rules about timezone adjustments for all sorts of
localities, including the following:

# Rule  NAMEFROMTO  TYPEIN  ON  AT  SAVELETTER/S
# Summer Time Act, 1916
RuleGB-Eire 1916only-   May 21  2:00s   1:00BST
RuleGB-Eire 1916only-   Oct  1  2:00s   0   GMT
# S.R.&O. 1917, No. 358
RuleGB-Eire 1917only-   Apr  8  2:00s   1:00BST
RuleGB-Eire 1917only-   Sep 17  2:00s   0   GMT


# Zone  NAMEGMTOFF  RULES   FORMAT  [UNTIL]
Zone Antarctica/Casey   0   -   zzz 1969
8:00-   WST # Western (Aus) Standard Time
Zone Antarctica/Davis   0   -   zzz 1957 Jan 13
7:00-   DAVT1964 Nov # Davis Time
0   -   zzz 1969 Feb
7:00-   DAVT
Zone Antarctica/Mawson  0   -   zzz 1954 Feb 13
6:00-   MAWT# Mawson Time

> I'm guessing that a better approach might be to have our time zone
> stuff inside our own API, which then could choose to call, for
> example, mktime() or pg_mktime(), which could each have different
> signatures.  Then the heuristics for matching one to the other are
> isolated to our thin API implementation, not to the underlying system-
> or pg-provided libraries.

> matching "stringy time zones" to numeric offsets for input dat

Re: [HACKERS] Redhat 7.3 time manipulation bug

[cbbrowne]

On Fri, 24 May 2002 06:10:39 PDT, the world broke into rejoicing as
Thomas Lockhart <[EMAIL PROTECTED]>  said:
> ...
> > But anybody using Unix dates as "general dates" has leaped into exactly the
> > same sort of trap that caused people to get so paranoid about Y2K.

> Certainly true. We don't use Unix dates as "general dates", we use the
> Unix time zone database and API for dates and times within the year
> range of 1903 to 2038. Well, up until now anyway...

I don't think going past 1970 is particularly safe; it certainly doesn't
seem to fit with ANSI...

By the way, the seemingly relevant link to look at for TZ info is 
http://www.twinsun.com/tz/tz-link.htm, linking to the data used by
various Unix implementations.

> Prior to the 1900s, the concept of time zones was more localized and
> not universally adopted. In the US, a first round of time zone
> standardization came with the transcontinental railroads in the 1860s.
> After 2038, it is a good bet that time zones will resemble those in
> use today, but they are as much a political construct as a physical
> one so the details are subject to change.

Some of the zones are quite peculiar if you head to Africa and Asia;
there are some sitting on 15 minute intervales, rather than the usual 1h
intervals.

(The classic Canadian timezone joke is "World ends at 9:00; 9:30 in
Newfoundland".  For more information, see TZ='America/St_Johns')
--
(concatenate 'string "chris" "@cbbrowne.com")
http://www.ntlug.org/~cbbrowne/spreadsheets.html
"Heuristics (from the  French heure, "hour") limit the  amount of time
spent executing something.  [When using heuristics] it shouldn't take
longer than an hour to do something."

---(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] Redhat 7.3 time manipulation bug

[cbbrowne]

> On 22 May 2002, Ulrich Drepper wrote:
> 
> > On Wed, 2002-05-22 at 11:23, Tom Lane wrote:
> >
> > > Unix systems have
> > > *always* interpreted time_t as a signed offset from the epoch.
> >
> > No.  This always was an accident if it happens.
> >
> > > Do you
> > > really think that when Unixen were first built in the early 70s, there
> > > was no interest in working with pre-1970 dates?  Hardly likely.
> >
> > There never were files or any system events with these dates.  Yes.
> >
> > And just to educate you and your likes: the majority of systems on this
> > planet use mktime this way.  I hate using this as an argument, but
> > beside major Unixes M$ systems also do this.
> 
> M$ systems crashes regularly too ... is Redhat going to adopt that too?

Harbison and Steele indicates that:

  "Although the traditional return type of time is long, the value returned is 
usually of type unsigned long."

That is NOT a "Linux" reference; it was published before Linus had started 
working on his kernel project.

ANSI does not indicate that time_t is a signed int, signed long, or whatever.  
It is only defined to be an arithmetic type.

It would not be a bug for GLIBC to define time_t to be an unsigned int, with 
an epoch beginning of January 1, 1999.  That definition would conform to ANSI 
C.

Since that definition can conform to ANSI C, and Unix systems have more 
particularly been known to use unsigned ints with epoch of 1970, it is NOT 
reasonable to assume that time_t can be used to express dates that are at all 
ancient in the past.

Indeed, it is fairly _useful_ for different libc implementations to make 
different assumptions about things whose definitions are permitted to vary, as 
this makes it easier to call out as WRONG those systems that make up their own 
definitions.

People will no doubt get defensive about their own non-standard 
implementations of things; it is certainly far easier to cry "They're trying 
to play Microsoft!" than it is to be honest and actually look at the standards.
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www.cbbrowne.com/info/advocacy.html
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

-- 
(reverse (concatenate 'string "gro.mca@" "enworbbc"))
http://www.cbbrowne.com/info/linuxxian.html
As of next Monday, COMSAT will be flushed in favor of a string and two tin
cans.  Please update your software.



---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Redhat 7.3 time manipulation bug

[cbbrowne]

> --=-Z1lifK4QZqKV8kHqHfYT
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
> 
> On Wed, 2002-05-22 at 10:51, Lamar Owen wrote:
> 
> > What isn't funny is Oliver Elphick's results on Debian, running glibc 2.2=
> .5=20
> > (same as Red Hat 7.3's version).
> 
> This is a completely different version.  Once Debian updates (in a few
> years) they'll get the same result.
> 
> If you are misusing interfaces you get what you deserve.  At no time was
> it correct to use these functions for general date manipulation.  It
> always only was allowed to use them to represent system times and there
> was no Unix system before the epoch.  Therefore you argumentation is
> completely wrong.
> 
> If you need date manipulation write your own code which work for all the
> times you want to represent.

This is indeed a problem with dates on LIBC, because even if it is 
theoretically satisfactory to describe dates within some range within 2^31 
seconds of 1970, that is certainly NOT satisfactory for describing all dates 
of interest unless you're being terribly parochial about what is to be 
considered "of interest."

My father's birth falls within 2^31 seconds of 1970, but the Battle of 
Agincourt doesn't.

Any backup of any Unix system in history falls within 2^31 seconds of 1970, 
but there are people alive whose births don't.

People get away with using Unix dates as a "general" date type when they don't 
have to work outside a limited range.  If/when there is a move to 64 bit 
values, that will provide something with enough range to cover history back to 
ridiculously early times, relieving the limit.

But anybody using Unix dates as "general dates" has leaped into exactly the 
same sort of trap that caused people to get so paranoid about Y2K.
--
(concatenate 'string "cbbrowne" "@acm.org")
http://www.cbbrowne.com/info/oses.html
Do Roman paramedics refer to IV's as "4's"? 

-- 
(concatenate 'string "aa454" "@freenet.carleton.ca")
http://www.ntlug.org/~cbbrowne/linuxxian.html
"So, when you typed in the date, it exploded into a sheet of blue
flame and burned the entire admin wing to the ground? Yes, that's a
known bug. We'll be fixing it in the next release. Until then, try not
to use European date format, and keep an extinguisher handy."
-- [EMAIL PROTECTED] (Tequila Rapide) 



---(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] Native Win32, How about this?

[cbbrowne]

> A binary version of PostgreSQL for Windows should not use the cygwin
> dll. I know and understand there is some disagreement with this
> position, but in this I'm sure about this.

That may ultimately be desirable.

In the short term, it is likely preferable to use cygwin.

It is only necessary to point at MySQL for an example.  Cygwin is used there.
<http://www.mysql.com/downloads/mysql-3.23.html>  It is being used widely, 
"crap" or not.

Cygwin may not ultimately be the ideal thing to use; we don't yet live in 
Pangloss' "Best of All Possible Worlds," and thus have to live with some 
things not being ideal.

If having the installer install Cygwin as well as the DBMS makes it easy to 
have something usable soon, and this allows 100,000 WinFolk to try out 
PostgreSQL, then that's a Big Win.  Out of 100K users, surely two or three may 
be attracted into working on a more Panglossian solution.

It may be fair to say that none of those 100K folk would be using PostgreSQL 
to support HA applications involving hundreds of GB of data.  That's _fine_.

If there are new 100K folk using PostgreSQL/cygwin, _some_ of them will 
outgrow its capabilities, and come looking for improvements.

And as they're Windows users, accustomed to having to pay hefty amounts to 
Microsoft to get support no better than that provided by the Psychic Friends 
Network (see <http://www.bmug.org/news/articles/MSvsPF.html>), they'll 
doubtless be prepared to have to pay _something_ in order for 
"PostgreSQL/Win3K-Enterprise Edition" to become available.

That seems a not too unreasonable path towards the "Best of All Possible 
Worlds."  There may be a bit of hyperbole in the above, but any time Voltaire 
gets quoted, that's likely to happen :-).
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www.cbbrowne.com/info/wp.html
Eagles may soar, but weasels don't get sucked into jet engines.

-- 
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www.cbbrowne.com/info/multiplexor.html
It's a  little known fact  that the Dark  Ages were caused by  the Y1K
problem.





msg16930/pgp0.pgp
Description: PGP signature

Re: [HACKERS] Monitoring backend activities

[cbbrowne]

> Hi everybody,
>  I'm a hookie in this discussion list. Well, my intent is to get some
> informations about PostgreSQL internals to work on a project. There
> is an excellent GPL'ed tool to work with Oracle called TOra. It is as
> good as TOAD and SQL Navigator from Quest Software. As a meaning of
> collaborate with the Open Source world i was thinking in port TOra to
> PostgreSQL. So, we'll have a great database and a great tool to manage
> it.

I think that would be "rookie;" the term "hookie" refers to what you're 
"playing" if you skip school.

>  Problem is: reading PostgreSQL documentation i didn't find any
> information about system tables having runtime informations as Oracle
> has. And one of the great features of TOra is the possibility to see
> in charts, in real-time, all kind of I/O operations, memory usage,
> queries being executed, etc...

The only problem I see is that TOra already seems quite well supported for 
PostgreSQL.  I'm running it at the moment, and it works quite well...
--
(concatenate 'string "cbbrowne" "@cbbrowne.com")
http://www.cbbrowne.com/info/lsf.html
"Put simply, the antitrust laws in this country are basically a joke,
protecting us just enough to not have to re-name our park service the
Phillip Morris National Park Service." 
-- Courtney Love, Salon.com, June 14, 2000

-- 
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www.cbbrowne.com/info/rdbms.html
Rules of the Evil Overlord  #220. "Whatever my one vulnerability is, I
will fake a  different one. For example, ordering  all mirrors removed
from the palace, screaming and flinching whenever someone accidentally
holds up a mirror, etc. In the climax when the hero whips out a mirror
and thrusts it at my face,  my reaction will be ``Hmm...I think I need
a shave.''"  <http://www.eviloverlord.com/>



-- 
(reverse (concatenate 'string "moc.enworbbc@" "sirhc"))
http://www.cbbrowne.com/info/linuxxian.html
As of next Monday, MACLISP will no longer support list structure.
Please downgrade your programs.





msg16907/pgp0.pgp
Description: PGP signature

Re: [HACKERS] How much work is a native Windows application?

[cbbrowne]

> [EMAIL PROTECTED] wrote:
>>> I think, and I know people are probably sick of me spouting
>>> opinions, that if you want a Windows presence for PostgreSQL, then
>>> we should write a real Win32 version.
>>
>> The crucial wrong word is the word "we."

>> If _you_ want a Windows presence, then _you_ should write a real
>> Win32 version.  That clearly attaches responsibility to someone who
>> is interested.

> I have already said that I am willing to write the pieces for a
> Windows port.  The issue is changes in PostgreSQL required to do it.

No, I don't think you understand.

If you're planning to do a port, then _all_ changes are your
responsibility.  Nobody ought to need to change PostgreSQL in order for
you to write a Windows port; that, in fact, would be a waste of time,
having several people working on something that should probably be done
by one person.
--
(concatenate 'string "aa454" "@freenet.carleton.ca")
http://www.ntlug.org/~cbbrowne/x.html
Why are they called apartments, when they're all stuck together? 

---(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] How much work is a native Windows application?

[cbbrowne]

> I think, and I know people are probably sick of me spouting opinions,
> that if you want a Windows presence for PostgreSQL, then we should
> write a real Win32 version.

The crucial wrong word is the word "we."

If _you_ want a Windows presence, then _you_ should write a real Win32 
version.  That clearly attaches responsibility to someone who is interested.
--
(reverse (concatenate 'string "gro.mca@" "enworbbc"))
http://www.cbbrowne.com/info/unix.html
"I'm not switching from slrn.   I'm quite confident that anything that
*needs* to be posted in HTML is fatuous garbage not worth my time."
-- David M. Cook <[EMAIL PROTECTED]>

-- 
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/spreadsheets.html
Rules of the Evil Overlord #166.  "If the rebels manage to trick me, I
will make a  note of what they did  so that I do not  keep falling for
the same trick over and over again." <http://www.eviloverlord.com/>





msg16822/pgp0.pgp
Description: PGP signature

Re: [HACKERS] Musings

[cbbrowne]

On Mon, 06 May 2002 00:50:25 +1000, the world broke into rejoicing as
Gavin Sherry <[EMAIL PROTECTED]>  said:
> On Sun, 5 May 2002 [EMAIL PROTECTED] wrote:
> > On Sun, 05 May 2002 10:01:57 EDT, the world broke into rejoicing as
> > mlw <[EMAIL PROTECTED]>  said:
> > > It is sunday morning and I have been musing about some PostgreSQL issues. As
> > > some of you are aware, my dot com, dot died, and I am working on a business
> > > plan for a consulting company which, amongst other things, will feature
> > > PostgreSQL. As I am working on the various aspects, some issue pop up about
> > > PostgreSQL.
> > > 
> > > Please don't take any of these personally, they are only my observations, if
> > > you say they are non issues I would rather just accept that we disagree than
> > > get into a nasty fight. They *are* issues to a corporate acceptance, I have
> > > been challenged by IT people about them.
> > > 
> > > (1) Major version upgrade. This is a hard one, having to dump out and
> > > restore a database to go from 7.1 to 7.2 or 7.2 to 7.3 is really a
> > > hard sell. If a customer has a very large database, this represents a
> > > large amount of down-time. If they are running on an operating system
> > > with file-size limitations it is not an easy task. It also means that
> > > they have to have additional storage which amount to at least a copy
> > > of the whole database.
> > 
> > All of these things are true, and what you should throw back at the IT
> > people is the question:
> > 
> >   "So what do you do when you upgrade from Oracle 7 to Oracle 8?  How
> >about the process of doing major Informix upgrades?  Sybase?  Does it
> >not involve some appreciable amounts of down-time?"

> This is most definately the wrong way of thinking about this. I'm not
> saying that Mark sets a simple task, but the goals of Postgres should
> never be limited to the other products out there.

Apparently you decided to fire back an email before bothering to read
the paragraph that followed, which read:

  There may well be possible improvements to the PostgreSQL upgrade
  process; "zero-downtime, zero-extra space upgrades" do not seem likely
  to be amongst those things.

Yes, there may well be improvements possible.  I'd think it unlikely
that they'd emerge today or tomorrow, and I think it's silly to assume
that all responses must necessarily be of a technical nature.

IT guys that are firing shots to the effect of "We expect zero time
upgrades" are more than likely playing some other agenda than merely
"we'd like instant upgrades."

For them to expect instant upgrades when _much_ more expensive systems
offer nothing of the sort suggests to me that the _true_ agenda has
nothing to do with upgrade time, and everything to do with FUD.

If that's the case, and I expect FUD is in play in this sort of
situation, then the purely technical response of "we might try that
someday" is a Dead Loss of an answer.

If they refuse to move from Oracle to PostgreSQL because PostgreSQL has
no "instant transparent upgrade" scheme as compared to Oracle, which
_also_ has no "instant transparent upgrade," then do you realistically
think that the lack of a "instant transparent upgrade" has ANYTHING to
do with the choice?

I'm merely suggesting that suitable questions head back to determine if
the question is an honest one, or if it's merely FUD.
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www.cbbrowne.com/info/lisp.html
When man stands on toilet, man is high on pot. -Confucius

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Musings

[cbbrowne]

On Sun, 05 May 2002 10:01:57 EDT, the world broke into rejoicing as
mlw <[EMAIL PROTECTED]>  said:
> It is sunday morning and I have been musing about some PostgreSQL issues. As
> some of you are aware, my dot com, dot died, and I am working on a business
> plan for a consulting company which, amongst other things, will feature
> PostgreSQL. As I am working on the various aspects, some issue pop up about
> PostgreSQL.
> 
> Please don't take any of these personally, they are only my observations, if
> you say they are non issues I would rather just accept that we disagree than
> get into a nasty fight. They *are* issues to a corporate acceptance, I have
> been challenged by IT people about them.
> 
> (1) Major version upgrade. This is a hard one, having to dump out and
> restore a database to go from 7.1 to 7.2 or 7.2 to 7.3 is really a
> hard sell. If a customer has a very large database, this represents a
> large amount of down-time. If they are running on an operating system
> with file-size limitations it is not an easy task. It also means that
> they have to have additional storage which amount to at least a copy
> of the whole database.

All of these things are true, and what you should throw back at the IT
people is the question:

  "So what do you do when you upgrade from Oracle 7 to Oracle 8?  How
   about the process of doing major Informix upgrades?  Sybase?  Does it
   not involve some appreciable amounts of down-time?"

There may well be possible improvements to the PostgreSQL upgrade
process; "zero-downtime, zero-extra space upgrades" do not seem likely
to be amongst those things.

The last time I did an SAP upgrade, there were _five days_ of
down-time.  Not 15 minutes, not "none," but rather a figure rather close
to a week.

For the IT guys to have sour grapes over upgrades requiring some time
and disk space is unsurprising; for them to pretend it is only a problem
with PostgreSQL is just dishonest.
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www.cbbrowne.com/info/
"Marketing Division, Sirius Cybernetics Corp: A bunch of mindless
jerks who'll be the first against the wall when the revolution comes."
-- The Hitchhiker's Guide to the Galaxy

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] PostgreSQL mission statement?

[cbbrowne]

> mlw <[EMAIL PROTECTED]> writes:
> > Just out of curiosity, does PostgreSQL have a mission statement?

> Nope.  Given the wide variety of views among the developer community,
> I think we'd have a tough time agreeing on a mission statement, unless
> it was so generic as to be meaningless ...

Well, I think one of the things that has been agreed on that _isn't_
that generic is:
  "We use a Berkeley style license, and prefer it that way."

:-)
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www.ntlug.org/~cbbrowne/rdbms.html
To err is human, to moo bovine. 

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] mV database tools

[cbbrowne]

> I suppose arrays are PostgreSQL's equivalent of multi-valued data (is it
> possible to have arrays of arrays?)  So it could be argued that
> PostgreSQL already provides part of what Arthur wants.

It seems to me that there would be a whopping lot of value to the exercise of 
figuring out some way of "layering" MVD on top of a relational database, even 
if only to provide something sufficiently analytical to cope with the 
perpetual claims of:

  "MultiValued Databases are Vastly, Spectacularly, the Bestest Kind of
   Database ever imagined in the universe!  No, really they are!"

It might not be necessary to go all the way to fully layering such a thing atop 
PostgreSQL, although it would be a nice riposte to be able to respond with:

  "Been there, done that.  Of _COURSE_ PostgreSQL supports MultiValue."
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www.cbbrowne.com/info/lisp.html
Including a destination in the CC list that will cause the recipients'
mailer to blow out is a good way to stifle dissent.
-- from the Symbolics Guidelines for Sending Mail

-- 
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://www.cbbrowne.com/info/spreadsheets.html
"Starting a project in C/C++ is a premature optimization."
-- Peter Jensen





msg16544/pgp0.pgp
Description: PGP signature

Re: [HACKERS] "make report"

[cbbrowne]

> I'd like to implement *something* to help us collect information on what
> platforms actually have what features. This would be useful, for
> example, for figuring out whether any platforms are lacking 8 byte
> integers or are missing timezone infrastructure.
> 
> I was thinking about something like "make report" which would mail the
> results of ./configure to, say, the ports mailing list. We could mention
> it in the text message printed at the end of the make cycle.
> 
> Comments? Suggestions?

Suggestion:  Why not embed this information into the binary, and provide some 
way of extracting it.

(There's a Linux kernel option that allows something similar, so it wouldn't 
be something unprecedented.)

If all the config information is embedded in the binary, automatically, at 
compile time, then this allows the ability to be _certain_ that:

- "Oh, that was compiled with a really stupid set of compiler options; you'll 
have to recompile!"

- "That was compiled without support for FOO, but with support for BAR."

- "Announcement, people:  Look out for whether or not your distribution 
compiled PostgreSQL with proper support for 64 bit integers.  Several 
distributions got this wrong with the 7.4.17 release, and you can see if it's 
OK by looking for LONG_LONG_REVISED in the embedded configuration information."

[Downside:  "Announcement, script kiddies:  If you find option 
UPDATE_DESCR_TABS=1 in the configuration information, then there's a very easy 
root exploit..."]
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/x.html
Rules of  the Evil  Overlord #176.  "I will add  indelible dye  to the
moat. It won't  stop anyone from swimming across,  but even dim-witted
guards should be  able to figure out when someone  has entered in this
fashion." <http://www.eviloverlord.com/>

-- 
(concatenate 'string "cbbrowne" "@acm.org")
http://www3.sympatico.ca/cbbrowne/spiritual.html
Including a destination in the CC list that will cause the recipients'
mailer to blow out is a good way to stifle dissent.
-- from the Symbolics Guidelines for Sending Mail





msg16196/pgp0.pgp
Description: PGP signature