Peter Eisentraut wrote:
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list
at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers
reviews and approves it.
I was hoping that we're
Bruce Momjian wrote:
Peter Eisentraut wrote:
I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
features to it.
Author states:
I understand that XML support is planned and at least partially
implemented for 8.3, but many production instances will be unable (or,
in
Dave Page wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
features to it.
Author states:
I understand that XML support is planned and at least partially
implemented for 8.3, but many production
On 3/22/07, Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
I was hoping that we're deprecating contrib/xml2, so I wouldn't add more
features to it.
Author states:
I understand that XML support is planned and at least partially
Mike Rylander wrote:
A related question, however: Will the XML features being included in
8.3 support namespace prefix registration?
That is certainly the plan.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Peter Eisentraut wrote:
Mike Rylander wrote:
A related question, however: Will the XML features being included in
8.3 support namespace prefix registration?
That is certainly the plan.
Let me bounce my ostrich (sp?) head up here and say, thanks for your
work on this Peter.
Joshua D. Drake
On Mon, 2007-02-26 at 23:07 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2007-02-26 at 18:14 -0500, Tom Lane wrote:
What does this accomplish other than adding syntactic sugar over a
feature that really doesn't work well anyway?
This patch doesn't intend to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am playing with this now ... sorry for delay ...
- --On Wednesday, February 28, 2007 12:58:04 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Joshua D. Drake wrote:
We should add this to the mailing list signup
3:23 PM
To: John Bartlett
Cc: pgsql-hackers@postgresql.org; pgsql-patches@postgresql.org; 'Heikki
Linnakangas'
Subject: Re: [HACKERS] [PATCHES] - WIP Patch Updatable Cursor
On Wed, 28 Feb 2007, John Bartlett wrote:
Hi,
A list of ctids is stored in the file.
I would have thought these would
Not that I think that anyone owning both a law degree and a computer
in 2007 should legitimately be able to plead innocence here. FAST
Australia's lawyers are making themselves look like idiots, and the
same for every other company tacking on such notices. I think the
real bottom line
I have added this to the developer's FAQ to clarify the situtation of
posting a patch:
liPostgreSQL is licensed under a BSD license. By posting a patch
to the public PostgreSQL mailling lists, you are giving the PostgreSQL
Global Development Group the non-revokable right to
Joshua D. Drake wrote:
Bruce Momjian wrote:
I have added this to the developer's FAQ to clarify the situtation of
posting a patch:
liPostgreSQL is licensed under a BSD license. By posting a patch
to the public PostgreSQL mailling lists, you are giving the PostgreSQL
Bruce Momjian wrote:
I have added this to the developer's FAQ to clarify the situtation of
posting a patch:
liPostgreSQL is licensed under a BSD license. By posting a patch
to the public PostgreSQL mailling lists, you are giving the PostgreSQL
Global Development Group the
Bruce Momjian [EMAIL PROTECTED] writes:
Joshua D. Drake wrote:
We should add this to the mailing list signup pages and the welcome
pages to the lists.
Yep, good idea. Marc?
For -patches and -hackers, I agree. It seems a bit legalistic and
off-putting for the general lists, though.
On Thu, 1 Mar 2007 04:28, Bruce Momjian wrote:
I have added this to the developer's FAQ to clarify the situtation of
posting a patch:
liPostgreSQL is licensed under a BSD license. By posting a patch
to the public PostgreSQL mailling lists, you are giving the PostgreSQL
Global
FAST PostgreSQL wrote:
On Thu, 1 Mar 2007 04:28, Bruce Momjian wrote:
I have added this to the developer's FAQ to clarify the situtation of
posting a patch:
liPostgreSQL is licensed under a BSD license. By posting a patch
to the public PostgreSQL mailling lists, you are giving the
Bruce Momjian wrote:
FYI, I am not going to be comfortable accepting a final patch that
contains this email signature:
This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN
27 003 693 481. It is confidential to the ordinary user of the email
address to
Neil Conway wrote:
On Tue, 2007-02-27 at 14:52 -0800, Joshua D. Drake wrote:
Gonna have to concur with that. Not that the sig is legally binding
anyway, we do need to have a disclaimer in the email stating that you
are assigning to PGDG
I think it's pretty silly to start caring about
Neil Conway wrote:
On Tue, 2007-02-27 at 14:52 -0800, Joshua D. Drake wrote:
Gonna have to concur with that. Not that the sig is legally binding
anyway, we do need to have a disclaimer in the email stating that you
are assigning to PGDG
I think it's pretty silly to start caring about this
On Tue, 2007-02-27 at 16:20 -0800, Joshua D. Drake wrote:
Thus we may literally not have rights to the code. Do you really want to
go down the path of in 2 years, Fujitsu (No offense Fujitsu), but you
are the topic) decides that the code they provided is owned by them and
they didn't give us
Neil Conway wrote:
On Tue, 2007-02-27 at 16:20 -0800, Joshua D. Drake wrote:
Thus we may literally not have rights to the code. Do you really want to
go down the path of in 2 years, Fujitsu (No offense Fujitsu), but you
are the topic) decides that the code they provided is owned by them and
On Wed, 28 Feb 2007, John Bartlett wrote:
Hi,
A list of ctids is stored in the file.
I would have thought these would be stored in memory. If the set got
large, you'd use a temporary file the way other systems which overflow to
disk do?
The file is used to store the ctids during an
Bruce Momjian [EMAIL PROTECTED] writes:
Neil Conway wrote:
For the case in question, sure, requiring some clarification from FJ
would be reasonable. But more broadly, my point is that I think you're
fooling yourself if you think that requiring a disclaimer or explicit
transfer of copyright
Yes, I do. If there is an explicit claim, like an email footer or a
copyright in the code, we do try to nail that down.
AFAICT, the footer in question tries to make it illegal for us even to
have the message in our mail archives. If I were running the PG lists,
I would install filters
Joshua D. Drake [EMAIL PROTECTED] writes:
... In regards to your idea of a filter, there is no reason why
we couldn't install a filter that checks for signatures with specific
legal words and strips said signature automatically, responding to the
sender that we did so.
The problem is that if
Not that I think that anyone owning both a law degree and a computer
in 2007 should legitimately be able to plead innocence here. FAST
Australia's lawyers are making themselves look like idiots, and the
same for every other company tacking on such notices. I think the
real bottom line here
Joshua D. Drake [EMAIL PROTECTED] writes:
Well the problem is, it isn't the guy that sent the patch that is the
idiot. That guys has zero control over the matter, the signature is
going to be tacked on at the MTA level.
Sure, I know that and you know that. The problem we have to worry about
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2007-02-26 at 18:14 -0500, Tom Lane wrote:
What does this accomplish other than adding syntactic sugar over a
feature that really doesn't work well anyway?
This patch doesn't intend to implement group commit. I've changed the
meaning of
Based on this patch review, I am removing the patch from the patch
queue and requiring a resubmission.
---
Tom Lane wrote:
Dhanaraj M [EMAIL PROTECTED] writes:
Sorry for resubmitting this patch.
Just now I found a
OK, where are we on this patch?
without changes. This task have to do anybody who better know PostgreSQL
cache system than me.
Regards
Pavel
---
Pavel Stehule wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
Pavel Stehule wrote:
OK, where are we on this patch?
without changes. This task have to do anybody who better know PostgreSQL
cache system than me.
How about you submit a version without any caching, but which works
correctly; and we worry about optimizations later?
Pavel Stehule wrote:
OK, where are we on this patch?
without changes. This task have to do anybody who better know PostgreSQL
cache system than me.
How about you submit a version without any caching, but which works
correctly; and we worry about optimizations later?
I can update and send
OK, where are we on this patch?
---
Pavel Stehule wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
This patch doesn't seem to cope with cases where the supplied tuple has
the wrong number of columns, and it
Full_page_compress is not intended to use with PITR slave, but for the
case to keep both online backup and archive log for archive recovery,
which is very popular PostgreSQL operation now.
I've just posted my evaluation for the patch as a reply for another
thread of the same proposal (sorry, I
FYI, Neil has corrected this in CVS HEAD.
---
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
On Mon, 2006-09-04 at 15:19 -0400, Tom Lane wrote:
AFAICT it's just junk. It happens to be the input times
Roman Kononov wrote:
On 12/27/2006 01:15 PM, Tom Lane wrote:
I'm not convinced that you're fixing things so much as doing your best
to destroy IEEE-compliant float arithmetic behavior.
I think what we should probably consider is removing CheckFloat4Val
and CheckFloat8Val altogether,
On Thu, Jan 11, 2007 at 11:10:38PM +, Simon Riggs wrote:
On Thu, 2007-01-11 at 17:06 +, Gregory Stark wrote:
Having a CRC in WAL but not in the heap seems kind of pointless.
Yes...
If your
hardware is unreliable the corruption could anywhere.
Agreed.
I thought the point
Simon Riggs wrote:
On Thu, 2007-01-11 at 12:37 -0500, Bruce Momjian wrote:
The trace probe was incorrect
Yes, incomplete, no doubt. On that point you were 100% right to reject.
and kind of at an odd place. I don't
think we want to go down the road of throwing trace in everwhere, do
On Fri, 2007-01-12 at 11:44 -0500, Bruce Momjian wrote:
I think the right approach is to look at our existing code and come up
with places we want them, and add them in one shot. Doing thing
in small parts doesn't work too well with a project this size.
Will do.
--
Simon Riggs
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts value? This is not a zero-cost improvement.
Tom, how should this be tested? I assume some loop of the same query
over and
On Wed, 2007-01-10 at 23:32 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Fri, 2007-01-05 at 22:57 -0500, Tom Lane wrote:
Jim Nasby [EMAIL PROTECTED] writes:
On Jan 5, 2007, at 6:30 AM, Zeugswetter Andreas ADI SD wrote:
Ok, so when you need CRC's on a replicate (but not on the
Simon Riggs [EMAIL PROTECTED] writes:
COPY XLogInsert() #1 on oprofile results at 17% CPU
(full_page_writes = on)
But what portion of that is actually CRC-related? XLogInsert does quite
a lot.
Anyway, I can't see degrading the reliability of the system for a gain
in the
On Thu, 2007-01-11 at 09:01 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
COPYXLogInsert() #1 on oprofile results at 17% CPU
(full_page_writes = on)
But what portion of that is actually CRC-related? XLogInsert does quite
a lot.
Anyway, I
Gregory Stark [EMAIL PROTECTED] writes:
What did you think about protecting against torn writes using id numbers every
512 bytes.
Pretty much not happening; or are you volunteering to fix every part of
the system to tolerate injections of inserted data anywhere in a stored
datum?
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
What did you think about protecting against torn writes using id numbers
every
512 bytes.
Pretty much not happening; or are you volunteering to fix every part of
the system to tolerate injections of inserted data
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Pretty much not happening; or are you volunteering to fix every part of
the system to tolerate injections of inserted data anywhere in a stored
datum?
I was thinking to do it at a low level as the xlog records are
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Pretty much not happening; or are you volunteering to fix every part of
the system to tolerate injections of inserted data anywhere in a stored
datum?
I was thinking to do it at a
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
You understand wrong ... a tuple sitting on disk is normally read
directly from the shared buffer, and I don't think we want to pay for
copying it.
xlog records
Oh, sorry, had the wrong context in mind. I'm still
Tom Lane [EMAIL PROTECTED] writes:
Oh, sorry, had the wrong context in mind. I'm still not very impressed
with the idea --- a CRC check will catch many kinds of problems, whereas
this approach catches exactly one kind of problem.
Well in fairness I tossed in a throwaway comment at the end
On Tue, 2007-01-09 at 17:16 -0500, Bruce Momjian wrote:
Tom Lane wrote:
/* reset flag so that die() interrupt won't cause
problems */
vfdP-fdstate = ~FD_TEMPORARY;
+ PG_TRACE1(temp__file__cleanup, vfdP-fileName);
+
Simon Riggs [EMAIL PROTECTED] writes:
Tom Lane wrote:
The TRACE is in the wrong place no? I thought it was going to be after
the stat() operation so it could pass the file size.
We had that discussion already. If you only pass it after the stat()
then you cannot use DTrace, except when you
Simon Riggs wrote:
Also, I dunno much about DTrace, but I had the idea that you can't
simply throw a PG_TRACE macro into the source and think you are done
--- isn't there a file of probe declarations to add to? Not to mention
the documentation of what probes exist.
I didn't like
On Thu, Jan 11, 2007 at 12:35:25PM -0500, Tom Lane wrote:
I think the real criterion has to be is this probe useful to
developers?. I'm entirely uninterested in adding probes that are
targeted towards DBAs, as this one would have been --- if we think
there's a problem that a DBA would have,
On Thu, 2007-01-11 at 12:37 -0500, Bruce Momjian wrote:
The trace probe was incorrect
Yes, incomplete, no doubt. On that point you were 100% right to reject.
and kind of at an odd place. I don't
think we want to go down the road of throwing trace in everwhere, do we?
I would like to see a
On Thu, 2007-01-11 at 12:35 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Tom Lane wrote:
The TRACE is in the wrong place no? I thought it was going to be after
the stat() operation so it could pass the file size.
We had that discussion already. If you only pass it
On Thu, 2007-01-11 at 17:06 +, Gregory Stark wrote:
Having a CRC in WAL but not in the heap seems kind of pointless.
Yes...
If your
hardware is unreliable the corruption could anywhere.
Agreed.
Other DBMS have one setting for the whole server; I've never seen
separate settings for WAL
Am Mittwoch, 10. Januar 2007 01:41 schrieb Bruce Momjian:
Peter Eisentraut wrote:
Bruce Momjian wrote:
? %-A4.tex-ps: %.sgml $(ALLSGML) stylesheet.dsl bookindex.sgml
? $(JADE.tex.call) -V texdvi-output -V '%paper-type%'=A4 -o $@ $
+ ifndef DRAFT
+ [EMAIL PROTECTED] -s
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Patch applied. Thanks.
I added a comment about the unused bits in the header file.
Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts value? This is not a zero-cost
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts value? This is not a zero-cost improvement.
I haven't tested it. Agreed, it does add an AND operation to places
where
Nice, thanks a lot.
Tom Lane wrote:
Teodor Sigaev [EMAIL PROTECTED] writes:
Just a freshing for clean applying..
http://www.sigaev.ru/misc/user_defined_typmod-0.11.gz
Applied with some revisions, and pg_dump support and regression tests
added.
regards, tom lane
Heikki Linnakangas [EMAIL PROTECTED] writes:
What? I'm completely lost here. What does log_temp_files have to do with
the bits on the tuple header?
Nothing, it looks like Bruce replied to the wrong message at one point
while these two threads were active ...
regards,
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Patch applied. Thanks.
I added a comment about the unused bits in the header file.
Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts
Peter Eisentraut wrote:
Am Mittwoch, 10. Januar 2007 01:41 schrieb Bruce Momjian:
Peter Eisentraut wrote:
Bruce Momjian wrote:
? %-A4.tex-ps: %.sgml $(ALLSGML) stylesheet.dsl bookindex.sgml
? $(JADE.tex.call) -V texdvi-output -V '%paper-type%'=A4 -o $@ $
+ ifndef DRAFT
Bruce Momjian wrote:
Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
Can we be sure that a BCC build libpq is even safe to use given the
problems seen when using psql?
Well, I'd not trust it a lot, but surely we have to get it to build
before anyone can debug it ...
It
Alvaro Herrera wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
Can we be sure that a BCC build libpq is even safe to use given the
problems seen when using psql?
Well, I'd not trust it a lot, but surely we have to get it to build
before
Bruce Momjian wrote:
The rule re-runs the makefile for the specific target, and the target
modifies HTML.index, or it is only the HTML rule that modifies that.
Only the html rule modifies HTML.index.
That was a question I had. If that is true, it has to be:
%-A4.tex-ps: %.sgml
Peter Eisentraut wrote:
Bruce Momjian wrote:
The rule re-runs the makefile for the specific target, and the target
modifies HTML.index, or it is only the HTML rule that modifies that.
Only the html rule modifies HTML.index.
That was a question I had. If that is true, it has to be:
On Sat, Jan 06, 2007 at 09:20:53PM -0500, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Reason for no documentation was that CREATE INDEX and CREATE TABLE AS
SELECT already use this optimisation, but to my knowledge neither was/is
documented on those command
On 1/10/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
What about a Mingw or VC++ psql with a BCC libpq? Is it possible to
link something like that?
It would be nice to have the libpq at least able to pass the regression
tests.
you can use microsoft/mingw compiled DLL files but not library
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
... why is NAMEDATALEN exported at all?)
I think because it used to be used in libpq's notification structure.
Yeah, you're probably right. Maybe we should take it out of
postgres_ext.h and move it to
Simon Riggs wrote:
On Fri, 2007-01-05 at 22:57 -0500, Tom Lane wrote:
Jim Nasby [EMAIL PROTECTED] writes:
On Jan 5, 2007, at 6:30 AM, Zeugswetter Andreas ADI SD wrote:
Ok, so when you need CRC's on a replicate (but not on the master) you
Which sounds to me like a good reason to
In response to Bruce Momjian [EMAIL PROTECTED]:
I have applied a modified version of your patch. I renamed the
parameter to 'log_temp_files', for consistency, added documentation, and
improved the wording, particularly mentioning that the logging happens
at file deletion time.
Thanks.
--
Bill Moran wrote:
In response to Tom Lane [EMAIL PROTECTED]:
Bill Moran [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] wrote:
Might be more robust to say
if (trace_temp_files = 0)
I specified in the GUC config that minimum allowable value is -1.
I'd still tend
Bruce Momjian [EMAIL PROTECTED] writes:
+ A value of zero logs all temporary files, and positive
+ values log only files whose size is equal or greater than
+ the specified number of bytes.
Surely the measurement unit should be kbytes or disk blocks. And why
aren't you
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
+ A value of zero logs all temporary files, and positive
+ values log only files whose size is equal or greater than
+ the specified number of bytes.
Surely the measurement unit should be kbytes or disk
Patch applied.
---
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
The problem is that this requires two runs even to proof the
documentation,
which I
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Surely the measurement unit should be kbytes or disk blocks. And why
aren't you using that GUC UNITS infrastructure Peter put in?
Agreed. I have applied the following patch to make it kilobytes, and
documented it. I didn't put '-1kB'
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Surely the measurement unit should be kbytes or disk blocks. And why
aren't you using that GUC UNITS infrastructure Peter put in?
Agreed. I have applied the following patch to make it kilobytes, and
documented
In response to Tom Lane [EMAIL PROTECTED]:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Surely the measurement unit should be kbytes or disk blocks. And why
aren't you using that GUC UNITS infrastructure Peter put in?
Agreed. I have applied the following patch to make it
Bill Moran [EMAIL PROTECTED] writes:
In response to Tom Lane [EMAIL PROTECTED]:
and then zero
can be the off position, and we need not worry about whether -1 is
-1 byte or -1 kbyte.
All doing this does is make it impossible to log temp files of 1 byte.
How you figure that? It would make it
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Patch applied. Thanks.
I added a comment about the unused bits in the header file.
Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts value? This is not a zero-cost improvement.
I
Bill Moran [EMAIL PROTECTED] writes:
In response to Tom Lane [EMAIL PROTECTED]:
Hmm, that could be a little bit ugly. Suggestion: redefine the value
such that files *greater than* the given size are logged,
It already is that way, with 0 effectively meaning log all.
Oh, never mind,
Tom Lane wrote:
Bill Moran [EMAIL PROTECTED] writes:
In response to Tom Lane [EMAIL PROTECTED]:
and then zero
can be the off position, and we need not worry about whether -1 is
-1 byte or -1 kbyte.
All doing this does is make it impossible to log temp files of 1 byte.
How you
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Patch applied. Thanks.
I added a comment about the unused bits in the header file.
Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts value? This is not a zero-cost improvement.
SHOW
Bruce Momjian [EMAIL PROTECTED] writes:
SHOW ALL has:
log_temp_files | -1 | Log the
use of temporary files larger than th
Yeah, but if you do SET log_temp_files = -1, does it still say that?
I'm worried that will change it to -1024.
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts value? This is not a zero-cost improvement.
Tom, how should this be tested? I assume some loop of the same query
over and over again.
I'd
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
SHOW ALL has:
log_temp_files | -1 | Log
the use of temporary files larger than th
Yeah, but if you do SET log_temp_files = -1, does it still say that?
I'm worried that will
Bruce Momjian wrote:
%-A4.tex-ps: %.sgml $(ALLSGML) stylesheet.dsl bookindex.sgml
$(JADE.tex.call) -V texdvi-output -V '%paper-type%'=A4 -o $@ $
+ ifndef DRAFT
+ [EMAIL PROTECTED] -s HTML.index.start HTML.index || $(MAKE) $*
+ endif
What is the point of that?
--
Peter
Bruce Momjian wrote:
+ ifndef DRAFT
+ [EMAIL PROTECTED] -s HTML.index.start HTML.index || $(MAKE) $*
+ endif
Why are you using $*? This isn't a pattern rule.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Bruce Momjian wrote:
! draft:
! ifndef DRAFT
! ifneq ($(MAKECMDGOALS), draft)
How could this condition ever match?
! # Call ourselves with the DRAFT value set. This seems to be the only
! # way to set gmake variables in a rule.
! [EMAIL PROTECTED](MAKE) DRAFT=Y $(MAKECMDGOALS))
Peter Eisentraut wrote:
Bruce Momjian wrote:
? %-A4.tex-ps: %.sgml $(ALLSGML) stylesheet.dsl bookindex.sgml
? $(JADE.tex.call) -V texdvi-output -V '%paper-type%'=A4 -o $@ $
+ ifndef DRAFT
+ [EMAIL PROTECTED] -s HTML.index.start HTML.index || $(MAKE) $*
+ endif
What is the
Peter Eisentraut wrote:
Bruce Momjian wrote:
+ ifndef DRAFT
+ [EMAIL PROTECTED] -s HTML.index.start HTML.index || $(MAKE) $*
+ endif
Why are you using $*? This isn't a pattern rule.
Sorry, my mistake. Here is an patch to fix that.
--
Bruce Momjian [EMAIL PROTECTED]
Peter Eisentraut wrote:
Bruce Momjian wrote:
! draft:
! ifndef DRAFT
! ifneq ($(MAKECMDGOALS), draft)
How could this condition ever match?
On first call, 'draft' might be set, but in the recursive call, this
code will not be reached because DRAFT iss set.
Am Montag, 8. Januar 2007 05:10 schrieb Bruce Momjian:
Here is a patch that runs the build twice when HTML.index does not
exist, and once every time after that. This is not ideal, but it is a
start.
The problem is that this requires two runs even to proof the documentation,
which I think no
Peter Eisentraut wrote:
Am Montag, 8. Januar 2007 05:10 schrieb Bruce Momjian:
Here is a patch that runs the build twice when HTML.index does not
exist, and once every time after that. This is not ideal, but it is a
start.
The problem is that this requires two runs even to proof the
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
The problem is that this requires two runs even to proof the documentation,
which I think no one wants.
So what would the API be to signal you want a draft build?
gmake DRAFT=Y html
I'd vote for
gmake draft
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
The problem is that this requires two runs even to proof the documentation,
which I think no one wants.
So what would the API be to signal you want a draft build?
gmake DRAFT=Y html
I'd vote for
On Sun, Jan 07, 2007 at 12:42:06AM -0500, Bruce Momjian wrote:
Joshua D. Drake wrote:
On Sat, 2007-01-06 at 23:38 -0500, Tom Lane wrote:
Everyone using these tools knows about the two-pass behavior.
No, not everyone knows. In fact I would argue that most do not know. It
isn't
On Sun, Jan 07, 2007 at 11:46:29AM +, Simon Riggs wrote:
On Sun, 2007-01-07 at 03:53 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The patch sets HEAP_XMIN_COMMITTED on all of the rows loaded by COPY as
well.
I think you just talked yourself out of getting this
On Sun, 2007-01-07 at 12:59 +0100, Martijn van Oosterhout wrote:
On Sun, Jan 07, 2007 at 11:46:29AM +, Simon Riggs wrote:
On Sun, 2007-01-07 at 03:53 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The patch sets HEAP_XMIN_COMMITTED on all of the rows loaded by COPY as
101 - 200 of 660 matches
Mail list logo
