Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Could we get out of this by defining that "timeout" is
> > automatically reset at next statement end?
>
> I was hoping to avoid that, because it seems like a wart. OTOH,
> it'd
Ross J. Reedstrom wrote:
> On Fri, Apr 05, 2002 at 11:19:04AM -0500, Tom Lane wrote:
> > Jan Wieck <[EMAIL PROTECTED]> writes:
> > > Could we get out of this by defining that "timeout" is
> > > automatically reset at next statement end?
Bruce Momjian wrote:
> > > > Sorry I couldn't understand your point.
> > > > It seems the simplest and the most certain way is to call
> > > > 'SET QUERY_TIMEOUT per query. The way dosen't require
> > > > RESET at all. Is the overhead an issue ?
> > >
> > > What about psql and libpq. Doing a tim
Tom Lane wrote:
> Karel Zak <[EMAIL PROTECTED]> writes:
> > Is there some problem implement "SET ... ON ROLLBACK UNSET" ?
>
> Yes. See my previous example concerning search_path: that variable
> MUST be rolled back at transaction abort, else we risk its value being
> invalid. We cannot offer th
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Is an invalid search path really that critical (read security
> > issue)?
>
> It's not a security issue (unless the OID counter wraps around soon
> enough to let someone else get assigned the
Tom Lane wrote:
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> > Required frequency of *successful* vacuum over *all* tables.
> > We would have to remember something in pg_class/pg_database
> > and somehow force vacuum over "too-long-unvacuumed-tables"
> > *automatically*.
>
> I don't think this
Tom Lane wrote:
> We've hacked up pg_dump so that it won't dump objects inherited from
> template1. Unfortunately I have realized there are a couple of serious
> problems:
>
> 1. What if the inherited object is a table or a sequence? Its state may
> no longer be the same as it was in template1 (
Tom Lane wrote:
>
> Do we still need the lastsysoid column in pg_database if we do things
> this way? Seems like what you really want is to suppress all the
> objects that are in template0, so you really only need one lastsysoid
> value, namely template0's. The other entries are useless AFAICS.
Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
> > Where would you store the value if not in pg_database?
>
> No other ideas at the moment. I was just wondering whether there was any
> way to delete it entirely, but seems like we want to have the value for
> template0 available. The
Tom Lane wrote:
>
> More to the point, I think we have to assume old-style interface if we
> see ... LANGUAGE 'C' with no other decoration, because any other
> assumption is guaranteed to break all existing user-defined functions.
Just successfully loading an old-style C function doesn't
Bruce Momjian wrote:
> Also, seems like it is hidden enough in /contrib for it to stay. While
> I would not have added it myself, I do not feel strongly enough to
> remove Jan's commit. However, I am not going to mention it in the 7.0.3
> release notes.
>
> I want it removed from 7.1 /contrib.
Stephan Szabo wrote:
>
>There's a message on -general about a possible
> problem in the deferred RI constraints. He was doing a
> sequence like:
> begin
> delete
> insert
> end
> and having it fail even though the deleted key was back in
> place at the end.
Isn't that (delete and r
Tom Lane wrote:
> To bring this back from future nice solutions to the reality of what
> to do today, do people like the "template0" solution for now (7.1)?
> I can work on it if so.
Go for it.
Jan
--
#==#
# It's easier t
Hi,
I'd like make some changes on the 7.1 (to be) libpgtcl.
1. Make the large object access null-byte safe, when
libpgtcl is compiled against a 8.0 or higher version of
Tcl.
This would cause that a libpgtcl.so built on a system
with Tcl 8.0
Jan Wieck wrote:
> Hi,
>
> I'd like make some changes on the 7.1 (to be) libpgtcl.
>
> 1. Make the large object access null-byte safe, when
> libpgtcl is compiled against a 8.0 or higher version of
> Tcl.
>
> This would
Adam Haberlach wrote:
>In any case, can we create pgsql-politics so we don't have to go over
> this issue every three months? Can we create pgsql-benchmarks while we
> are at it, to take care of the other thread that keeps popping up?
pgsql-yawn, where any of them can happen as often and
Hi,
I'm about 99.67% sure that the lock type choosen in the
FOR UPDATE case (line 511 of parse_relation.c) should be
RowExclusiveLock instead of RowShareLock. Actually I get
"Deadlock risk" debug messages when selecting FOR UPDATE and
then really UPDATE.
Mikheev, Vadim wrote:
> > I'm about 99.67% sure that the lock type choosen in the
> > FOR UPDATE case (line 511 of parse_relation.c) should be
> > RowExclusiveLock instead of RowShareLock. Actually I get
> > "Deadlock risk" debug messages when selecting FOR UPDATE
Don Baccus wrote:
>
> ...
> I expect TOAST to work even better). Users will still be able change to
> larger blocksizes (perhaps a wise thing to do if a large percentage of their
> data won't fit into a single PG block). Users using the default will
> be able to store rows of *awesome* length,
Mikheev, Vadim wrote:
> > > So, I've run simple test (below) to check this. Seems that 7.1
> > > is faster than 7.0.3 (nofsync), and that SELECT FOR UPDATE in RI
> > > triggers is quite bad for performance.
> > > Also, we should add new TODO item: implement dirty reads
> > > and use them in RI tri
Bruce Momjian wrote:
> > Bruce Momjian writes:
> >
> > > ERROR: triggered data change violation on relation "primarytest2"
> >
> > We're getting this report about once every 48 hours, which would make it a
> > FAQ. (hint, hint)
> >
>
>
> First time I heard of it. Does anyone know more details?
Tom Lane wrote:
> The way that heap_update() and heap_delete() are currently coded, they
> hold the buffer context lock on the buffer containing the old tuple
> while they invoke heap_tuple_toast_attrs(). This strikes me as at least
> inefficient and at worst a source of deadlock. Is it possible
Tom Lane wrote:
> backend/commands/command.c has a routine is_view() that tests for
> view-ness by scanning pg_rewrite (all of it) to see if the given
> relation has any ON SELECT rules.
>
> This is only used to disallow AlterTableAddConstraint and
> LockTableCommand on views. While I don't care
Tom Lane wrote:
> Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> > Has anyone any input to offer on adding an arbitrary locking feature?
>
> > Where
> > GETLOCK "string" will lock on "string", the lock being only released at the
> > end of a transaction.
>
> > Any comments, suggestions or tips would b
Sinuhi Arroyo wrote:
> I`mtrying to make a select which envolves two tables with in a
> functionif the query is written this way: (this is just an example,
> not my query)
>
> a := (select count(*) from xx);
>
> it works fine, but if I type the query like this
>
> select count(*) from xx;
>
>
Tom Lane wrote:
> "Steve Howe" <[EMAIL PROTECTED]> writes:
> > create rule blah_update as
> > on update to blah
> >do
> > notify TestEvent;
>
> > UPDATE blah SET n1=n1+1; -- Won't crash the connection
> > UPDATE blah SET n1=2 WHERE var_field='aaa' AND n1=1 AND n2=2 AND arr_str IS
> > NU
Tim Perdue wrote:
> I thought the hackers team would be interested in knowing that SourceForge, as
> of Friday evening, is running on Postgres. Some 95,000 users and 12,500 Open
> Source projects are depending on your stuff, so I hope it's going to be stable
> for us. ;-)
Tim,
the PG core
Bruce Momjian wrote:
> Here are my open 7.1 items. Thanks for shrinking the list so far.
>
> ---
>
> FreeBSD locale bug
> Reorder INSERT firing in rules
I don't recall why this is wanted. AFAIK there's no reason
N
Ross J. Reedstrom wrote:
> On Fri, Jan 26, 2001 at 03:18:13PM -0500, Bruce Momjian wrote:
> > > The 'tmpwatch' program on Red Hat will remove the /tmp/.s.PGSQL.5432.lock
> > > file after the server has run 6 days. This will be a problem.
> > >
> > > We could touch (open) the file once every time
Bruce Momjian wrote:
> Here is another bug:
>
> test=> begin;
> BEGIN
> test=> INSERT INTO primarytest2 VALUES (5,5);
> INSERT 18757 1
> test=> UPDATE primarytest2 SET col2=1 WHERE col1 = 5 AND col2 = 5;
> ERROR: deferredTriggerGetPreviousEvent: event for tuple (0,10) not
> found
Schema?
J
Peter Eisentraut wrote:
> Jan Wieck writes:
>
> > Exactly the way you want it to do (open(2) and close(2) of a
> > UNIX domain socket) was what I had to do to get an old
> > Mach3-4.3BSD combo into a kernel-panic.
>
> The lock file is an ordinary
Damn,
the new EXECUTE command in PL/pgSQL is a security hole.
PL/pgSQL is a trusted procedural language, meaning that
regular users can write code in it. With the new EXECUTE
command, someone could read and write arbitrary files under
the postgres UNIX-useri
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > the new EXECUTE command in PL/pgSQL is a security hole.
> > PL/pgSQL is a trusted procedural language, meaning that
> > regular users can write code in it. With the new EXECUTE
>
KuroiNeko wrote:
> > Huh? This would only be true if all operations inside plpgsql are
> > executed as superuser, which they are not. Seems to me the existing
> > defense against non-superuser using COPY is sufficient.
>
> Sorry if I missed the point, but if I got it right, Pl/Pgsql EXECUTE will
Bruce Momjian wrote:
> > Hi Bruce,
> >
> > Any idea when it's due for??
>
> When? Probably not until 7.2, which is a pain.
We cannot use TOAST as is for BLOB/CLOB storage with a binary
IO interface over fastpath.
The reason is that you cannot force a column to be moved off
anyw
Olivier PRENANT wrote:
> Hi Bruce,
>
> Any idea when it's due for??
> I've been thining about writing a user function; But I'll get stuck with
> permission as a user function is running under the "postgres" or whatever
> user instead of the calling user.
>
> Also, what kind of binary interface are
Bruce Momjian wrote:
>
> I would LOVE to see it in a minor 7.1.X release.
It's *feature* with alot necessary coding in core
functionality below heap access methods. Not a good candidate
for a bugfix release.
Jan
>
>
> > Bruce,
> >
> > Thanks for replying (I know you're
Jaruwan Laongmal wrote:
[Charset windows-874 unsupported, skipping...]
> Dear Sir,
>
> I will highly appreciated if anyone could inform me how to solve the following
>problems in Postgres.
> Specifically, sometimes there are the following messages informed by postgres.
>
> -
Hi,
headed for LinuxWorld now. Will be back on the lists on
Monday 5th. Take care.
Jan
--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.
Stephan Szabo wrote:
>
> On Mon, 5 Feb 2001, Christopher Kings-Lynne wrote:
>
> > Just a quick question, when a column of a table is defined to be a foreign
> > key, is it implicitly indexed, or does one still need to explicitly CREATE
> > INDEX?
>
> The foreign key columns are not currently impli
Tom Lane wrote:
> I have looked a little bit at what it'd take to make SELECT INTO inside
> an EXECUTE work the same as it does in plain plpgsql --- that is, the
> INTO should reference plpgsql variables, not a destination table.
> It looks to me like this is possible but would require some nontri
Josh Berkus wrote:
> Tom, Jan, Michael,
>
> > While I have not looked closely, I seem to recall that plpgsql handles
> > INTO by stripping that clause out of the statement before it's passed to
> > the SQL engine. Evidently that's not happening in the EXECUTE case.
> >
> > Jan, do you agree this
Philip Warner wrote:
>
> P.S. Is Jan around? He's been very quiet recently...
He is,
just a little quiet. I can live with it either way. The main
problem, as said, is that we need to allow some keywords as
identifiers in PL/pgSQL like in the main parser. Actually we
added RES
Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
> >> Hmm, that's definitely what SQL99 uses for the syntax. I wonder where
> >> Jan got the SELECT INTO syntax --- did he borrow it from Oracle?
>
> > Sadly, we made it up.
>
> Ah so. Well, friendliness aside, I'd go with the spec's syn
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Quoting a recent message by Jan Wieck <[EMAIL PROTECTED]>:
> > :Do a
> > :
> > :GET DIAGNOSTICS SELECT PROCESSED INTO ;
> > :
> > :directly after an INSERT, UPDATE or
Tom Lane wrote:
> Adriaan Joubert <[EMAIL PROTECTED]> writes:
> > fdatasync() is available on Tru64 and according to the man-page behaves
> > as Tom expects. So it should be a win for us.
>
> Careful ... HPUX's man page also claims that fdatasync does something
> useful, but it doesn't. I'd recom
Philip Warner wrote:
>
> Unfortunately, I don't have an awful lot of free time at the moment, so I
> won't be able to look at this for at *least* as week.
I'll do it as soon as we decided about the final syntax and
keywords.
Jan
--
#==
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > I like this one - except for the OID which should IMHO read
> > INSERTED_OID.
>
> I just committed changes that make it RESULT_OID, but if you like
> INSERTED_OID better, we could change it...
Tom Lane wrote:
> Pam Withnall <[EMAIL PROTECTED]> writes:
> > in my java code I am creating 3 temporary tables, then calling a stored
> > procedure which calls another stored procedure.
> > then I drop the temporary tables.
> > the first time around , eveything is OK , then when repeating the ac
Bruce Momjian wrote:
>
> Yes, it seems storing info in shared memory and having a system table to
> access it is the way to go.
Depends,
first of all we need to know WHAT we want to collect. If we
talk about block read/write statistics and such on a per
table base, which
Michael Meskes wrote:
> Is anyone on this list in Hannover for CeBit? Maybe we could arrange a
> meeting.
Looks pretty much that I'll be still in Hamburg by then. What
are the days you planned?
Jan
--
#==#
# It's easi
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > What about a collector deamon, fired up by the postmaster and
> > receiving UDP packets from the backends. Under heavy load, it
> > might miss some statistic messages, well, but that's not
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > What about a collector deamon, fired up by the postmaster and
> > receiving UDP packets from the backends. Under heavy load, it
> > might miss some statistic messages, well, but that's not
Philip Warner wrote:
>
> But I prefer the UDP/Collector model anyway; it gives use greater
> flexibility + the ability to keep stats past backend termination, and,as
> you say, removes any possible locking requirements from the backends.
OK, did some tests...
The postmaster can create a
Alfred Perlstein wrote:
> * Jan Wieck <[EMAIL PROTECTED]> [010316 08:08] wrote:
> > Philip Warner wrote:
> > >
> > > But I prefer the UDP/Collector model anyway; it gives use greater
> > > flexibility + the ability to keep stats past backend termination,
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Uh - not much time to spend if the statistics should at least
> > be half accurate. And it would become worse in SMP systems.
> > So that was a nifty idea, but I think it'd cause much mo
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Does a pipe guarantee that a buffer, written with one atomic
> > write(2), never can get intermixed with other data on the
> > readers end?
>
> Yes. The HPUX man page for write(2) sez
Tom Lane wrote:
> Now this would put a pretty tight time constraint on the collector:
> fall more than 4K behind, you start losing data. I am not sure if
> a UDP socket would provide more buffering or not; anyone know?
Looks like Linux has something around 16-32K of buffer space
for UDP
Jan Wieck wrote:
> Tom Lane wrote:
> > Now this would put a pretty tight time constraint on the collector:
> > fall more than 4K behind, you start losing data. I am not sure if
> > a UDP socket would provide more buffering or not; anyone know?
>
> Looks like Li
Philip Warner wrote:
> At 13:49 16/03/01 -0500, Jan Wieck wrote:
> >
> >Similar problem as with shared memory - size. If a long
> >running backend of a multithousand table database needs to
> >send access stats per table - and had accessed them all
Tom Lane wrote:
> Samuel Sieb <[EMAIL PROTECTED]> writes:
> > Just as another suggestion, what about sending the data to a different
> > computer, so instead of tying up the database server with processing the
> > statistics, you have another computer that has some free time to do the
> > processi
Bruce Momjian wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Only shared memory gives us near-zero cost for write/read. 99% of
> > > backends will not be using stats, so it has to be cheap.
> >
> > Not with a circular buffer it's not cheap, because you need interlocking
> > on writes.
Bruce Momjian wrote:
> I have talked to Jan over the phone, and he has convinced me that UDP is
> the proper way to communicate stats to the collector, rather than my
> shared memory idea.
>
> The advantages of his UDP approach is that the collector can sleep on
> the UDP socket rather than having
Bruce Momjian wrote:
> > Larry Rosenman <[EMAIL PROTECTED]> writes:
> > > FYI, the WU-FTPD code (2.6.0 or better) has a couple of more platforms
> > > including UnixWare. The UnixWare code will need /dev/kmem permission to
> > > change it's stuff, so I don't know whether we want to do this or not
Tom Lane wrote:
>
> I thought of something I'd overlooked in my original proposal for error-
> handling upgrades: what about reporting where an error occurs in a PL
> function?
>
> Currently, plpgsql has a hack that prints a separate WARNING giving
> the error location, but this is pretty darn ug
Jinqiang Han wrote:
>
> hello£¬
> what is RIR rules in Rewriter? What RIR means?
> Thank you very much.
> Jinqiang Han
Retrieve-Instead-Retrieve
The name is based on history.
RETRIEVE was the PostQUEL keyword for what you know as SELECT. A rule
fired on a RETRIEVE event, that is an unconditiona
Russ Mercer wrote:
>
> How can I compile the UltraSQL version of PostgreSQL for Win32? I am looking for a
> Win32 version of PostgreSQL that does not depend on cygwin, and UltraSQL seems to
> work well.
>
> This site (http://techdocs.postgresql.org/guides/Windows) only points to the
> UltraSQL
Merlin Moncure wrote:
>
> TRY TEST WIN32 PORT. DATABASE GO BOOM! TRY FIX NOBODY CARE. WIN32
> PORT COME OUT MANY DATABASE GO BOOM! TRY HELP GET IGNORED. JUST WANT
> HELP. BUG FIX?
Pardonne moi?
What exactly did you test? If it is the PeerDirect Beta version of
PostgreSQL for Windows named
"Marc G. Fournier" wrote:
>
> On Wed, 2 Apr 2003, scott.marlowe wrote:
>
> > > > If that is a real objective, I'm surprised.
> > >
> > > The base source tree has always been as BSD pure as we can make it ... its
> > > never been kept a secret ...
> >
> > True. But not linking to LGPLd libs would
mlw wrote:
>
> Jan Wieck wrote:
> >[...]
> >screen? We have a pure BSD alternative that we could even ship with our
> >distro, time to retire the libreadline hooks.
> >
> >
> I certainly didn't want to open up this can of worms, that's for sure.
&g
[EMAIL PROTECTED] wrote:
> The issue is:
> Is the requirement of an LGPL library that is more than likely not already
> on your system a disqualification for a contrib function?
Yes.
Because the requirement of something that is more likely not found on
"usual" installations TOGETHER WITH that it
Peter Eisentraut wrote:
>
> Andrew Sullivan writes:
>
> > Is anyone interested in having pglog-rotator?
>
> What would get me a whole lot more excited is if the server could write
> directly to a file and do its own rotating (or at least reopening of
> files).
>From a technical point of view I
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
When we considered outervar1 as a constant, we could do the aggregate in
the subquery using computations, but when SUM(outervar1) is computed in
an above query, combining that with anything that is part of different
query level makes no sens
Bruce Momjian wrote:
You are going to love the answer to this question --- it already does
compression of any long fields when it is stored in the TOAST table.
Well, sort of. The compression algorithm is extremely poor compared to
anything Christopher mentioned. It was choosen because it's free (n
Tommi Maekitalo wrote:
Hi,
There was a german article in heise news. See
http://www.heise.de/newsticker/data/hps-23.05.03-000/.
MySQL gets stored procedures and transactions and all the nice features, you
need for a real database (and postgresql already has) by throwing the code
away an replac
Tom Lane wrote:
Some of the Red Hat guys have been trying to work through the NIST SQL
compliance tests. So far they've found several things we already knew
about, and one we didn't:
-- TEST:0434 GROUP BY with HAVING EXISTS-correlated set function!
SELECT PNUM, SUM(HOURS) FROM WORKS
G
Michael Paesold wrote:
>
> Jan Wieck wrote:
> > > In any case, why don't we get a patch against 7.3, and make an
> > > announcement and let people who are interested use it and test it. With
> > > in-field testing it'd probably be safe enough. :)
>
Justin Clift wrote:
Tom Lane wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
"wal_debug" is seldom used outside of Postgresql source development or unusual
system failures, and should therefore go last.
BTW, it occurs to me that wal_debug is one of the hacker-only variables
that probably ought not
Okay, separate documentation might work ;-)
Jan
Josh Berkus wrote:
Jan,
No, not documenting it IS a good move.
I couldn't disagree more. Undocumented options? Who are we, Microsoft?
If there's a button people will
press it, if there's a switch people will turn it on and if there's a
slo
Peter Galantha wrote:
Hello,
is there a way to recover data from a damaged database if
a.) we have some but not all datafiles
b.) we have all datafiles but system tables are currupted
The situation is extremely critical so we're interested in all possible
solutions even if it's time consuming o
Tom Lane wrote:
BTW, I would not approve of a response along the lines of "can't you
#ifdef to the point that there are no code changes in the Unix builds?"
No you can't, unless you want to end up with an unmaintainable mess
of #ifdef spaghetti. The thing that makes this hard is the tradeoff
betw
Dann Corbit wrote:
PostgreSQL's regression tests (IMHO) are much better than
MySQL's crash-me scripts.
They are less thorough in coverage, but not too bad.
Right, we are still missing this test that proves 10,000 CREATE+DROP
TABLE will ensure that PostgreSQL is slower than MySQL, if you don't
VA
Dann Corbit wrote:
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Are you volunteering to create it? Step right up.
No. And as an outsider, I rather doubt if any procedures I developed
would be taken very seriously. If such procedures are to be developed,
I suspect that th
Alvaro Herrera wrote:
Also they don't test things they don't support. Is there a test for
subselects? What about concurrency? Transactional issues? What about
performance when they have their "transaction support" enabled?
Sure don't they. Like their NUMERIC data type, that can *store* any
pre
The Hermit Hacker wrote:
On Fri, 20 Jun 2003, Dann Corbit wrote:
Designing tests is busywork. Desiging tests is boring. Nobody wants to
design tests, let alone interpret the results and define correct
baselines. But testing is very, very important.
But we do do testing ... we even design testin
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
I sure want two-phase commit. I don't remember it as being rejected,
and we certainly need it, independent of replication.
Is 2PC a real-world solution to any real-world problem? I have never
seen a satisfactory explanation of what you do
Josh Berkus wrote:
Anyway, I would vote for a first implemenation for 2PC which addressed the
commit-then-crash issue in some expedient-but-not-reliable way, and putting
2PC in /contrib with a "not for production use" warning. Some people will
use it in production anyway, and hopefully one or m
Thank's Robert,
that was probably what Bruce needs to call me every other hour now ...
Jan
Robert Treat wrote:
On Sat, 2003-06-21 at 22:55, Bruce Momjian wrote:
Andrew Dunstan wrote:
>
> Maybe a better strategy would be to get a release out soon but not wait 6
> months for another release which
Dann Corbit wrote:
-Original Message-
From: Jan Wieck [mailto:[EMAIL PROTECTED]
What do you think is the way to become an insider?
Join the CVS tree and make a large and valuable contribution to the
project.
Go ahead, let's see it.
I have contributed a lot of crap over the years.
scott.marlowe wrote:
On Mon, 23 Jun 2003, Dann Corbit wrote:
> [Dann Corbit wrote a lot]
> [...]
It may be reassuring to think your product is very well tested before it
goes out the door, but it's a false security, proven over and over by
commercial products that simply don't work in the field b
Dann Corbit wrote:
-Original Message-
From: Jan Wieck [mailto:[EMAIL PROTECTED]
Sent: Monday, June 23, 2003 10:10 PM
To: scott.marlowe
Cc: Dann Corbit; Bruce Momjian; Tom Lane; Jason Earl;
PostgreSQL-development
Subject: Re: [HACKERS] Two weeks to feature freeze
scott.marlowe wrote
Dann Corbit wrote:
-Original Message-
From: Jan Wieck [mailto:[EMAIL PROTECTED]
Sent: Monday, June 23, 2003 10:30 PM
To: Dann Corbit
Cc: scott.marlowe; Bruce Momjian; Tom Lane; Jason Earl;
PostgreSQL-development
Subject: Re: [HACKERS] Two weeks to feature freeze
[snip]
I personally think
The Hermit Hacker wrote:
On Tue, 24 Jun 2003, Dann Corbit wrote:
I did something about it. I raised the issue.
Is it really so that whoever it is that raises a question is also the
one who must fix the issue raised?
A strange model indeed.
Its worked for us ...
Sorry Marc, but that ain't entirely
The Hermit Hacker wrote:
On Tue, 24 Jun 2003, Bruce Momjian wrote:
The Hermit Hacker wrote:
> On Tue, 24 Jun 2003, Dann Corbit wrote:
>
> > I did something about it. I raised the issue.
> > Is it really so that whoever it is that raises a question is also the
> > one who must fix the issue raised
Kaare Rasmussen wrote:
> That seems too vague for TODO. We might as well add "Make PostgreSQL
> faster". :-)
'K, can you add that one too? :)
How about "* Remove all bugs from the source". Can you put that in TODO ?
:-)
Change that into "* Remove bugs from source code" and get a patent on
it.
On Wed, 25 Jun 2003, Shridhar Daithankar wrote:
On 25 Jun 2003 at 14:50, Andreas Pflug wrote:
> Jan Wieck wrote:
> > Change that into "* Remove bugs from source code" and get a patent on
> > it. Should be a nobrainer (as in those guy's have no brains)
> > considering th
Bruce Momjian wrote:
See my recent commit of src/tools/pgtest. It might be a good start.
I was wondering if some existing framework, like from the Apache Xalan
package, would be a better point to start from? I hate to say it, Bruce,
but you try to reinvent the wheel by starting with a sled.
Jan
Stuart wrote:
Tom Lane wrote:
Stephan Szabo <[EMAIL PROTECTED]> writes:
As a side question, it looks to me that the code stores the first trigger
records in memory and then after some point starts storing all new records
on disk. Is this correct? I'd wonder if that's really what you want in
gen
Marc G. Fournier wrote:
On Wed, 25 Jun 2003, Robert Treat wrote:
Seems like we should also allow for a windows specific distribution of libpq
as well.
I thought that the win32 stuff was being included as part of the base
distribution? IF so, wouldn't such already be included in any
libpq.tar.gz w
Dear PostgreSQL community,
it is with great pleasure that I would like to let you all know that I
recently joined Afilias, a domain name registry services company that
runs the .info top level domain and also provides core registry services
to .org and a variety of other country code TLDs. (http:/
401 - 500 of 970 matches
Mail list logo
