Andrew Sullivan wrote:
On Tue, Oct 28, 2003 at 01:09:36AM -0500, Bruce Momjian wrote:
I am grouping the above two items together --- I thought the idea was to
give people a way to load 7.4 in a fairly rapid manner --- we now have
the ability to do ALTER TABLE ADD CONSTRAINT, but it lacks ANALYZE
s
Bruce Momjian wrote:
Joshua D. Drake wrote:
Hello,
Well the reason I brought it up was the rather interesting discussion
that Jan had today about Vacuum.
I was wondering if we were going to explore that before the 7.4 release?
No, I am afraid we are way past time time for that kind of addition
Bruce Momjian wrote:
Jan Wieck wrote:
> In fact, even though I was debugging the backend regularly, I removed -g
> and added it only when I wanted to debug.
>
It did somethimes in the past proove to be good luck to have symbols in
a core file accidentially. If you want to find t
Bruce Momjian wrote:
pgman wrote:
Jan Wieck wrote:
> >> >> > What Peter was advocating in that thread was that we enable -g by
> >> >> > default *when building with gcc*. I have no problem with that, since
> >> >> > there is (alleg
ivan wrote:
hi
can we change initdb when view pg_user is createing to :
CREATE VIEW pg_user AS \
SELECT \
usename, \
usesysid, \
usecreatedb, \
usesuper, \
usecatupd, \
''::text as passwd, \
valuntil, \
useconfig \
F
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
What happens instead is that vacuum not only evicts the whole buffer
cache by forcing all blocks of said table and its indexes in, it also
dirties a substantial amount of that and leaves the dirt to be cleaned
up by all the other ba
Gaetano Mendola wrote:
Bruce Momjian wrote:
I can confirm this bug in CVS.
Dropping the pkey from table b in fact drops the unique index from it.
The SPI plan cached to check if a row deleted from table a is still
referenced from table b "can" (and in your case does) use an index scan
on table
To add some medium-hard data to the discussion, I hacked a PG 7.3.4 a
little. The system I am talking about below run's an artificial
application that very well resembles the behaviour of a TPC-C benchmark
implementation. Without vacuuming the database, it can just so sustain a
factor 5 scaled
Bruce Momjian wrote:
Jan Wieck wrote:
Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> Tom Lane writes:
>>
>> > What Peter was advocating in that thread was that we enable -g by
>> > default *when building with gcc*. I have no problem with that, since
>>
Bruce Momjian wrote:
Peter Eisentraut wrote:
Tom Lane writes:
> What Peter was advocating in that thread was that we enable -g by
> default *when building with gcc*. I have no problem with that, since
> there is (allegedly) no performance penalty for -g with gcc. However,
> the actual present be
There is no backward link from a heap tuple to it's index entries. So if
you have 3 indexes on a table and do an update, you need at least 2 more
index lookups just to set that bit, if you somehow manage to remember by
what index you found this heap tuple in the first place.
On update-heavy tab
Bruce Momjian wrote:
Tatsuo Ishii wrote:
> Yes. I don't think that 2PC is a solution for robustness in face of
> network failure. It's too slow, to begin with. Some sort of
> multi-master system is very desirable for network failures, &c., but
> I don't think anybody does active/hot standby wit
Rod Taylor wrote:
On Mon, 2003-10-13 at 21:26, Jan Wieck wrote:
Why do people wait until the EMT cannot give the life-saving infusion
any more before they realize that "invincible" isn't that great at all?
Some dumb-user/fat-finger/ooops protection is surely welcome, but there
Rod Taylor wrote:
>> > Allow superuser (dba?) the ability to turn off foreign key checks/all
>> > constraints/triggers, not settable from postgresql.conf?
>>
>> Is that one really necessary for 7.4 now that adding foreign keys is
>> apparently much faster?
If you reconfigure your systems to fo
Bruce Momjian wrote:
Christopher Kings-Lynne wrote:
> Changes
> ---
> Allow superuser (dba?) the ability to turn off foreign key checks/all
> constraints/triggers, not settable from postgresql.conf?
Is that one really necessary for 7.4 now that adding foreign keys is
apparently much faster?
Tom Lane wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
Now that we have Statement-level triggers, is there any reason we shouldn't
have triggers on SELECT?
Plenty, although I'm too tired to recall 'em all. The fundamental
problem with this is that it turns SELECT into an operation with
side-eff
Bruce Momjian wrote:
Henry B. Hotz wrote:
>> Well, why do we have it enabled at all? If it's to speed compilation, we
>> may as well enable it on other platforms where -pipe works, of which
>> Linux is one.
>
>My gcc 2.95.3 manual says:
>
>-pipe Use pipes rather than temporary files fo
Joshua D. Drake wrote:
Hello,
I believe that the Int8/BigInt items are known issues but I have a
knew programmer that ran into it
over the weekend (he didn't call me when he encountered the problem,
when he should of) and we have a
customer that burned some significant time on it as well. Wil
Bruce Momjian wrote:
Christopher Kings-Lynne wrote:
>>Well, with the CREATE CONSTRAINT TRIGGER you _can_, but we already have
>>a consensus that we don't _want_ that. Probably we should declare it
>>deprecated and remove it in 7.5. And the option currently under
>>discussion is exactly what wil
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Oh, that makes me feel better. Do we have timings for this code?
This is just a single data point, but I made a table of 1 million
rows containing just the int4 primary key column (values 0-1million
in a somewhat random order). Then I cop
Bruce Momjian wrote:
Wow, that's a heap of code --- that's my only comment. :-)
Not really.
I'm not sure what conditions could possibley cause SPI_prepare to return
NULL, but it'd be certainly better to check that. Other than that, looks
good to me.
Jan
---
Bruce Momjian wrote:
Jan Wieck wrote:
Just committed a small fix for PL/Tcl.
I don't find it on the TODO, but you might want to add it to the release
notes.
* Fixed PL/Tcl's spi_prepare to accept full qualified type names in
the parameter type list.
Oops, properly added
Stephan Szabo wrote:
On Tue, 30 Sep 2003, Tom Lane wrote:
I see where Stephan is coming from, but in my mind disabling consistency
checks ought to be a feature reserved to the DBA (ie superuser), who
presumably has some clue about the tradeoffs involved. I don't think
ordinary users should be abl
Stephan Szabo wrote:
On Tue, 30 Sep 2003, Jan Wieck wrote:
Stephan Szabo wrote:
> On Tue, 30 Sep 2003, Tom Lane wrote:
>
>> I see where Stephan is coming from, but in my mind disabling consistency
>> checks ought to be a feature reserved to the DBA (ie superuser), who
>>
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
I think I can accept it to be the choice of the DBA what to do. Pg_dump
has that kind of options already, one can choose between COPY and INSERT
for example. Why not adding the choice of dumping FKeys as ALTER TABLE
or CREATE CONS
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
I think we need someway of telling postgres to suppress a foreign key check.
Well, the subtext argument here is "do we fix it by providing a way to
suppress the check, or do we fix it by making the check fast enough to
be tolerable
Tom Lane wrote:
Lamar Owen <[EMAIL PROTECTED]> writes:
This isn't necessarily true. That old of a version of PostgreSQL is probably
running on a quite out-of-date OS -- for instance, if the OS was Red Hat
Linux, then the point at which 6.2.1 was shipped was RHL 5.0. Can you even
compile Postgr
Joshua D. Drake wrote:
Hello,
Don't know if my vote counts here, but ANYTHING that makes pg_dump
more correct should be
backpatched. It is one thing to have index bloat, it is entirely another
to not be able to correctly backup
and restore.
Patch applied to REL7_3_STABLE.
Jan
Tom Lane wrote:
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
4. Use the parser's coerce_to_boolean procedure, so that nonbooleans
will be accepted in exactly the same cases where they'd be accepted
in a boolean-requiring SQL construct (such as CASE). (By default,
none ar
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
That eliminated, a cast should be dumped if one or more of the three
objects (source, target and function) are not builtin AND all the
non-builtin objects belong to namespaces included in the dump.
Where "builtin" is define
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
I classify this problem as a bug. Objections?
The question is not whether it is a bug, the question is what is correct
behavior instead.
Not yet, but when we have a decision and a fix it'll be the criterium
for applying it to 7.
The offending source code is in pg_dump.c line 3953, where at the lack
of an underlying conversion function and thus no clear namespace
relationship pg_dump simply ignores the cast.
IMHO a binary compatible cast should be dumped if one or both namespaces
of the underlying data types is included
Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
I think calling it 'here-document' quoting is possibly unwise - it is
sufficiently different from here documents in shell and perl contexts to
make it confusing.
I agree. I've tried to think of a better alternative name, but without
m
Can we add digits to the allowed character set of the marker? It'd make
life easier for languages that check if the quoting marker actually
occurs in the text to be quoted.
Jan
Tom Lane wrote:
Sean Chittenden <[EMAIL PROTECTED]> writes:
Using $$[.*]\n as a lexical token is a quasi-problematic
sendmail.cf
Sean Chittenden wrote:
>> The $$FOO proposal I put forward earlier was consciously modeled on
>> here-documents.
> Couldn't we allow << at the beginning of the line to mean 'here' document?
No; you could easily be breaking existing queries, for example
Let me jump in for half a second
Tom Lane wrote:
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
I made a patch to fix this, but in testing it I noticed that the stats
system doesn't work on shared tables as I was expecting it too (as my
latest patch requires it too :-). It treats instances of shared tables
in separate databas
Bruce Momjian wrote:
Jan Wieck wrote:
Bruce Momjian wrote:
> Sounds good. I just think keywords in general are weird to use for
> quoting. We use "'" for quoting, so something similar like another
> operator combination would be nice. I have never been fond of the
Bruce Momjian wrote:
Sounds good. I just think keywords in general are weird to use for
quoting. We use "'" for quoting, so something similar like another
operator combination would be nice. I have never been fond of the
here-document approach, though I can see the value of doing
here-documen
Kurt Roeckx wrote:
On Tue, Sep 09, 2003 at 02:10:20AM -0700, Kevin Brown wrote:
> I could go for Jan's idea of putting a random key into the messages,
> if anyone feels that we should not trust to the kernel to enforce the
> packet source address restriction. But the memcmp() test seems a clear
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
ERROR is the cleanest way, but I'd vote for conversion to boolean to
keep the damage within reason.
Which style of conversion did you like? These were the choices:
3. Try to convert nonbooleans to boolean using plpgsql's
Tom Lane wrote:
Following up this gripe
http://archives.postgresql.org/pgsql-sql/2003-09/msg00044.php
I've realized that plpgsql just assumes that the test expression
of an IF, WHILE, or EXIT statement is a boolean expression. It
doesn't take any measures to ensure this is the case or convert
t
Tom Lane wrote:
I was about to say "I give up, let's just take out the comparison".
Your point is interesting but easily avoided; if we aren't going to check
fromaddr anymore then there's no need to use recvfrom(), it could as
well be recv() and save the kernel a few cycles.
Which then get's us
says it limits for recv()
but we are using recvfrom() ... there might be a little difference on
that platform ...
Jan Wieck wrote:
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
Redhat 7.1 says
The file descriptor sockfd must refer to a socket. If the
socket is of
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
Redhat 7.1 says
The file descriptor sockfd must refer to a socket. If the
socket is of type SOCK_DGRAM then the serv_addr address is
the address to which datagrams are sent by default, and
the
Redhat 7.1 says
The file descriptor sockfd must refer to a socket. If the
socket is of type SOCK_DGRAM then the serv_addr address is
the address to which datagrams are sent by default, and
the only address from which datagrams are received. If
Looks like the tes
They are both structures of type sockaddr_in (sin_family 2 is AF_INET
whereas sin_family 10 would've been AF_INET6), and all relevant fields
of the structure look the same to me. The problem lies in the padding
bytes that make sockaddr_in the same size as sockaddr.
Since the static structure pg
Kurt Roeckx wrote:
On Thu, Sep 04, 2003 at 05:01:54PM -0400, Jan Wieck wrote:
Kurt Roeckx wrote:
>It could be useful to have a warning at the following line:
>
>if (memcmp(&fromaddr, &pgStatAddr, fromlen))
>continue;
Kurt Roeckx wrote:
It could be useful to have a warning at the following line:
if (memcmp(&fromaddr, &pgStatAddr, fromlen))
continue;
That way you can rule out that that is a problem.
Anyway, I still didn't see the error message he got i
Bupp Phillips wrote:
Will this have the native Windows port?
Approximately "maybe" :-)
Jan
""Marc G. Fournier"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
On Tue, 2 Sep 2003, postgresql wrote:
> Hi all
> Can anyone tell me the approximate pg 7.5 release date?
Summer of '04
Kurt Roeckx wrote:
On Thu, Sep 04, 2003 at 01:39:04AM -0400, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Doesn't the stats collector use unix domain sockets, not IP?
No. IIRC, we deliberately chose IP/UDP because it had buffering
behavior we liked.
Once you said it was because n
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
Okay, my proposal would be to have a VACUUM mode where it tells the
buffer manager to only return a page if it is already in memory, and
some "not cached" if it would have to read it from disk, and simply skip
the page in
Some well known database that is very popular amongst people who care
more for their data than for license fees uses few very big files that
are statically allocated (if using files instead of raw devices).
Sure does Oracle internally maintain some sort of filesystem. But this
is more due to ot
lease don't give us any vague "some other resident
process". This only indicates you don't really know what it requires for
a process to be able to read or write data in PostgreSQL.
Jan
Shridhar Daithankar wrote:
On 22 Aug 2003 at 11:03, Jan Wieck wrote:
Tom Lane wrote:
> Ja
Jan Wieck wrote:
Another way to give autovacuum some hints would be to return some number
as commandtuples from vacuum. like the number of tuples actually
vacuumed. That together with the new number of reltuples in pg_class
will tell autovacuum how frequent a relation really needs scanning
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
Shridhar Daithankar wrote:
Umm.. What does FSM does then? I was under impression that FSM stores page
pointers and vacuum work on FSM information only. In that case, it wouldn't
have to waste time to find out which pages to clean
Shridhar Daithankar wrote:
On Friday 22 August 2003 16:23, Manfred Koizar wrote:
On Fri, 22 Aug 2003 12:15:33 +0530, "Shridhar Daithankar"
<[EMAIL PROTECTED]> wrote:
>> Which leads us to a zero gravity vacuum, that does the lazy vacuum for
>> pages currently available in the buffer cache only. [.
Bruce Momjian wrote:
Is there a TODO here?
Maybe!? It's one of these premature things noone can tell by now. So the
TODO would be "investigation" for now.
Jan
---
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECT
Tom Lane wrote:
Stephan Szabo <[EMAIL PROTECTED]> writes:
select * from fk where not exists(select * from pk where pk.key=fk.key)
and key is not null;
(doing seq scan/subplan doing index scan - which is probably close to the
current system)
Actually, even that would probably be noticeably better
It has been a big pleasure to me to get to know you,
and a big honor to work with you.
Do swidanie i bolshoi sbaseebo, Vadim.
Jan
--- Vadim Mikheev <[EMAIL PROTECTED]> wrote:
> FarewellIt's time for formal acknowledgement that
> I'm not in The Project any more.
>
> I'm not interested in small
Marcus Börger wrote:
ATM i have a patch doing the following:
Connect:
If PQprotocolVersion() is available and >= 3 PQparameterStatus() is available
then i check the server version. Else i check the lib version (*).
If the version to check is >= 7.2 ido one of the following:
- If one of PQprotoc
Bruce Momjian wrote:
Marcus B?rger wrote:
However it may be very usefull to terminate any open transaction before
reusing a persisten connection. Typically this happens when the same script
runs again. But anyway using transactions together with persistent conenctions
in a multithreaded environment
Marcus Börger wrote:
Here's the current log while reusing the persistent connection:
DEBUG: InitPostgres
DEBUG: StartTransactionCommand
DEBUG: query: select getdatabaseencoding()
DEBUG: ProcessQuery
DEBUG: CommitTransactionCommand
DEBUG: StartTransactionCommand
DEBUG: query: RESET ALL
DEBUG
Bruce Momjian wrote:
Marcus B?rger wrote:
BM> Marcus, would you check if PHP is using RESET ALL when passing
BM> persistent connection to new clients? We added that capability a few
BM> releases ago, specifically for PHP persistent connections, but I don't
BM> think that ever got into the PHP code
Joe Conway wrote:
ivan wrote:
ok, but php should build this lang for postgres i think
so, we should talk with php group ?
I have been talking with several people about this on-and-off for a
while now. If I can find some time in the next few months, I will
probably write it (if no one beats me to
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
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
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:/
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
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
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.
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
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
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
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
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]
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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. :)
>
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
[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
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
"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
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
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
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
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
601 - 700 of 970 matches
Mail list logo
