Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
I assume we never came to a final conclusion on how to do CREATE
FUNCTION without double-quoting.
Many discussions, but no final conclusion in sight, it seems. That
\beginliteral stuff is psql
How is that relevant? It's still parseable with parameter placeholders in
place of literal parameters.
*NO PARSING*
The script must be stuffable into PQexec in total, backend does the rest.
Presumably \beginliteral \endliteral would be psql's way of specifying
parameters to ship over as
Andrew Dunstan wrote:
Tom Lane wrote:
Some people think a sql syntax solution is needed, and some do not.
So does this get resolved by a vote?
A non-sql-syntax solution is useless.
Regards,
Andreas
---(end of broadcast)---
TIP 1: subscribe
On Thursday 11 September 2003 09:33, Andreas Pflug wrote:
*NO PARSING*
The script must be stuffable into PQexec in total, backend does the rest.
Again: not psql, but sql language itself must provide this.
No out-of-band, because this would require splitting the script in pieces.
What's
Richard Huxton wrote:
On Thursday 11 September 2003 09:33, Andreas Pflug wrote:
*NO PARSING*
The script must be stuffable into PQexec in total, backend does the rest.
Again: not psql, but sql language itself must provide this.
No out-of-band, because this would require splitting the script in
On Thu, 10 Sep 2003, Doug McNaught wrote:
But Perl/DBI does escaping for you, so all you'd have to do is:
$sth = $dbh-prepare
(CREATE FUNCTION foo(x text) RETURNS text AS ? LANGUAGE 'plpgsql');
$sth-execute($function_body);
where $function_body is the unescaped form of the function.
[EMAIL PROTECTED] (Matthew T. O'Connor) wrote:
On Wed, 2003-09-10 at 15:57, Bruce Momjian wrote:
I assume the attached patch is what you want done to fix this. Applied.
It quotes table names for vacuum and analyze, and uppercases the
keywords for clarity.
Yeah, this is basically what I
On Thursday 11 September 2003 10:40, Andreas Pflug wrote:
Richard Huxton wrote:
On Thursday 11 September 2003 09:33, Andreas Pflug wrote:
*NO PARSING*
The script must be stuffable into PQexec in total, backend does the rest.
Again: not psql, but sql language itself must provide this.
No
On Wed, 2003-09-10 at 12:03, Bruce Momjian wrote:
Because MinGW/Msys doesn't come with flex/bison by default, I have added
those derived files to the WIN32_DEV branch in CVS.
I'm confused. Right on the MinGW download page is a link for
bison-1.875.
---(end of
On Thursday 11 September 2003 17:30, Matthew T. O'Connor wrote:
On Wed, 2003-09-10 at 12:03, Bruce Momjian wrote:
Because MinGW/Msys doesn't come with flex/bison by default, I have added
those derived files to the WIN32_DEV branch in CVS.
I'm confused. Right on the MinGW download page is a
Someone asked me a question about view and function permissions. I
assumed all object access done by a view would be based on the
permissions on the view, and not the permissions of the objects.
While table access done in a view follows this outline, function call
access does not. In my tests
Jon Jensen [EMAIL PROTECTED] writes:
On Thu, 10 Sep 2003, Doug McNaught wrote:
But Perl/DBI does escaping for you, so all you'd have to do is:
Only because the FE protocol is new and the DBD driver hasn't switched to
using it.
$sth = $dbh-prepare
(CREATE FUNCTION foo(x text) RETURNS
I'm confused. Right on the MinGW download page is a link for bison-1.875.
Yep, but I had problems with it. Author confirmed that there could be some
problems creating processes (for example M4). However if You make it work,
I'll be interested to know how. Check the MinGW mailing list
On Thursday 11 September 2003 18:00, Zeugswetter Andreas SB SD wrote:
I'm confused. Right on the MinGW download page is a link for
bison-1.875.
Yep, but I had problems with it. Author confirmed that there could be
some problems creating processes (for example M4). However if You make
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Some people think a sql syntax solution is needed, and some do not.
So does this get resolved by a vote?
A vote is a little premature when we don't have fully-developed
alternatives to choose from. The psql
On Thursday 11 September 2003 18:08, Darko Prenosil wrote:
On Thursday 11 September 2003 18:00, Zeugswetter Andreas SB SD wrote:
I'm confused. Right on the MinGW download page is a link for
bison-1.875.
Yep, but I had problems with it. Author confirmed that there could be
some
Bruce Momjian wrote:
Tom Lane wrote:
The discussion so far today seems to be entirely a rehash of arguments
already made (and in many cases already rebutted). Rather than wasting
list bandwidth with this, I think each camp ought to go off and do their
homework. Give us *details* of how your
Bruce Momjian [EMAIL PROTECTED] writes:
Another idea would be to enable another set of quoting characters, like:
Yeah, I was toying with that also; it would be nearly the same as the
psql literal proposal, but pushed into the backend. I am not sure what
the quoting symbols should look like
Andreas Pflug wrote:
Bruce Momjian wrote:
Tom Lane wrote:
The discussion so far today seems to be entirely a rehash of arguments
already made (and in many cases already rebutted). Rather than wasting
list bandwidth with this, I think each camp ought to go off and do their
homework.
Bruce Momjian [EMAIL PROTECTED] writes:
Uh, the problem with long keywords is that you are then requiring the
_parser_ to identify those keywords, and at that point, the entire text
between the keywords has been sliced up by the lexer, which will
certainly make it a mess. I might be wrong
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Uh, the problem with long keywords is that you are then requiring the
_parser_ to identify those keywords, and at that point, the entire text
between the keywords has been sliced up by the lexer, which will
certainly make it a mess.
Bruce Momjian [EMAIL PROTECTED] writes:
Someone asked me a question about view and function permissions. I
assumed all object access done by a view would be based on the
permissions on the view, and not the permissions of the objects.
Table references are checked according to the owner of the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Uh, the problem with long keywords is that you are then requiring the
_parser_ to identify those keywords, and at that point, the entire text
between the keywords has been sliced up by the lexer, which will
certainly make it a mess. I
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Someone asked me a question about view and function permissions. I
assumed all object access done by a view would be based on the
permissions on the view, and not the permissions of the objects.
Table references are checked
At 12:03 AM 9/11/03 -0400, Matthew T. O'Connor wrote:
Adam, can you please give this a test as you are the person who caught
the bug in the first place.
Thanks,
Matthew T. O'Connor
I applied your patch and it works fine for me.
--- Adam Kavan
---(end of
Andreas Pflug wrote:
Bruce Momjian wrote:
You mean if the special quotes are -- and --, - would be the
same as '-'?
If they work as the standard ' quote (and that seems to be Toms
intention), obviously.
Besides, we have to care specially about --. Remember the complaints
Sergio A. Kessler wrote:
Too sad, all special chars are used up for operators
also '{' '}' are used ?
I've only seen this in ACLs, so it might be usable. Tom, Bruce?
Regards,
Andreas
---(end of broadcast)---
TIP 6: Have you searched our
Andreas Pflug wrote:
Sergio A. Kessler wrote:
Too sad, all special chars are used up for operators
also '{' '}' are used ?
I've only seen this in ACLs, so it might be usable. Tom, Bruce?
Something that includes ' would be clearest. I thought of ' and ',
but this would break:
Patch applied. You might want to look at pg_dump/dumputils.c::fmtId()
for a function that does smart quoting.
---
Matthew T. O'Connor wrote:
On Wed, 2003-09-10 at 15:57, Bruce Momjian wrote:
I assume the attached patch
Bruce Momjian wrote:
Something that includes ' would be clearest. I thought of ' and ',
but this would break:
I'm not sure that using a quote is necessarily clearest. But it's a
matter of taste. I had thought of {{ and }} as maybe working.
[snip]
One clean way would be to use {' to start a
Bruce Momjian [EMAIL PROTECTED] writes:
Something that includes ' would be clearest. I thought of ' and ',
but this would break:
if var 'yes'
People seem to be assuming that this feature needs to be impervious to
whitespace and being adjacent to other things. I believe we could make
it
On Thu, 11 Sep 2003, Tom Lane wrote:
People seem to be assuming that this feature needs to be impervious to
whitespace and being adjacent to other things. I believe we could make
it a good deal more robust if both the opening and closing markers
(whatever they are) are required to stand
Bruce Momjian [EMAIL PROTECTED] writes:
Well, it sure sounds like a bug. What logic is there that table access
use the view permissions, but not function access? Could we just use
SECURITY DEFINER for function calls in views?
You're confusing two distinct questions, I think. One is how we
Tom Lane wrote:
I believe we could make
it a good deal more robust if both the opening and closing markers
(whatever they are) are required to stand alone on a line.
Hard to detect whitespace might trip things up. I wish I had a $ for
every time that has made my life difficult.
cheers
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I believe we could make
it a good deal more robust if both the opening and closing markers
(whatever they are) are required to stand alone on a line.
Hard to detect whitespace might trip things up. I wish I had a $ for
every time
On Thu, 2003-09-11 at 15:02, Bruce Momjian wrote:
Patch applied. You might want to look at pg_dump/dumputils.c::fmtId()
for a function that does smart quoting.
OK, thanks.
---(end of broadcast)---
TIP 8: explain analyze is your friend
On Thu, 2003-09-11 at 08:12, Christopher Browne wrote:
Something I am feeling a little suspicious of is that I haven't seen,
in the logs, pg_autovacuum looking at pg_ tables.
I know that if we don't periodically vacuum such system tables as
pg_class, pg_attribute, pg_statistic, and
Jon Jensen [EMAIL PROTECTED] writes:
Is there a reason not to use here documents?
The $$FOO proposal I put forward earlier was consciously modeled on
here-documents. We cannot use exactly the shell syntax for
here-documents, though, mainly because we already have meaning assigned
to strings
Matthew T. O'Connor wrote:
On Thu, 2003-09-11 at 08:12, Christopher Browne wrote:
Something I am feeling a little suspicious of is that I haven't seen,
in the logs, pg_autovacuum looking at pg_ tables.
I know that if we don't periodically vacuum such system tables as
pg_class,
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
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I believe we could make
it a good deal more robust if both the opening and closing markers
(whatever they are) are required to stand alone on a line.
Hard to detect whitespace might trip things up. I wish I
Matthew T. O'Connor [EMAIL PROTECTED] writes:
On Thu, 2003-09-11 at 08:12, Christopher Browne wrote:
[Rummaging around...] These tables are being added for template1, but
apparently not for main databases. That looks like a bit of a fly
in the ointment...
I designed it that way. It was my
Andreas Pflug wrote:
solution would be a great enhancement, details are now merely a question
of taste.
While this sounds nearly done for me, as there seems some fundamental
consense, I'll will probably have to wait for 7.5?
Yes, has to wait for 7.5.
--
Bruce Momjian
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
here-document approach, though I can see the
Tom Lane wrote:
Jon Jensen [EMAIL PROTECTED] writes:
Is there a reason not to use here documents?
The $$FOO proposal I put forward earlier was consciously modeled on
here-documents. We cannot use exactly the shell syntax for
here-documents, though, mainly because we already have meaning
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
here-document approach, though
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane 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
regression=#
Jan Wieck wrote:
The beauty of here-documents is that you specify your closing tag on a
per usage base and can vary that depending on the content you need to
enclose. Keep in mind that this literal mechanism is not only used for
PL/pgSQL, but for other languages like PL/Tcl and PL/Perl
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane 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
[EMAIL PROTECTED] (Matthew T. O'Connor) writes:
On Thu, 2003-09-11 at 08:12, Christopher Browne wrote:
Something I am feeling a little suspicious of is that I haven't seen,
in the logs, pg_autovacuum looking at pg_ tables.
I know that if we don't periodically vacuum such system tables as
On Thu, 11 Sep 2003, Bruce Momjian wrote:
I would definitely like to see us adopt a proposal that is like
here-documents to the extent that there's a family of possible
terminator markers and not only one. But we'll have to adjust the
syntax a little bit. If you don't like $$FOO, what
Bruce Momjian [EMAIL PROTECTED] writes:
Yes, that is true. I didn't like the beginning-of-line requirement for
here documents for that reason. However, we are already requiring the
thing to be at the beginning of the line. You are saying it is safer to
make it at the beginnning of a line
Bruce Momjian [EMAIL PROTECTED] writes:
So you are requiring the identical text to appear at the beginning and
end of the quote, rather than a here document that would be:
END
...
END
or in your example:
$$END
...
END
Yes, I was thinking of
Jon Jensen wrote:
On Thu, 11 Sep 2003, Bruce Momjian wrote:
I would definitely like to see us adopt a proposal that is like
here-documents to the extent that there's a family of possible
terminator markers and not only one. But we'll have to adjust the
syntax a little bit. If you
Bruce Momjian writes:
Tom Lane wrote:
Jon Jensen [EMAIL PROTECTED] writes:
Is there a reason not to use here documents?
The $$FOO proposal I put forward earlier was consciously modeled on
here-documents. We cannot use exactly the shell syntax for
here-documents, though, mainly
On Thu, 11 Sep 2003, Tom Lane wrote:
It is possible that we could allow the start marker to be not at the
beginning of its line, which would create structures very very close
to shell here-documents:
CREATE FUNCTION foo() RETURNS int AS $$FUNCTION
... text here ...
On Thu, 2003-09-11 at 17:11, Tom Lane wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
I designed it that way. It was my understanding that all of the system
tables pg_class etc... are shared tables, available in all databases,
but actually stored as only one central set of real
Tilo Schwarz [EMAIL PROTECTED] writes:
What about the Python approach: The literal text is enclosed either in a pair
of three single quotes or three double quotes.
That might be okay if we were working in a vacuum, but we aren't. Among
other things, the SQL spec tells us what 'quote''' ...
Matthew T. O'Connor [EMAIL PROTECTED] writes:
On Thu, 2003-09-11 at 17:11, Tom Lane wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
I designed it that way. It was my understanding that all of the system
tables pg_class etc... are shared tables, available in all databases,
but actually
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
So you are requiring the identical text to appear at the beginning and
end of the quote, rather than a here document that would be:
END
...
END
or in your example:
$$END
...
END
Yes, I was thinking of
On Thu, 2003-09-11 at 18:25, Tom Lane wrote:
BTW, I am not sure it is a good idea to suppress redundant vacuuming
of shared tables in the first place. The trouble with doing so is that
if you only vacuum pg_shadow through template1, then only template1 will
ever have up-to-date statistics
Bruce Momjian [EMAIL PROTECTED] writes:
... You are saying it is safer to
make it at the beginnning of a line _and_ have it be something that
isn't used in SQL, but $$ is used in Perl, so I don't see the big
advantage either way --- once you say X has to begin at the beginning of
the line, we
Below is the email that prompted me to add the derived files to
WIN32_DEV CVS.
However, most people don't want them in there, so I have removed them,
and updated the web page to recommend the nightly snapshots (which have
the derived files), and mentioned the tools that will be needed for a
CVS
Sean Chittenden wrote:
Backend only forks(). I think you would be better off using
Makefile macros to _remove_ those two libraries.
I see this:
$(filter crypt.o getaddrinfo.o inet_aton.o snprintf.o strerror.o path.o
thread.o, $(LIBOBJS))
Seems you need the reverse.
Tom Lane wrote:
Keep in mind that we have two different requirements: the quote start
marker has to be recognizable while we are parsing SQL (or possibly
plpgsql) code. The quote end marker has to be recognizable while we are
scanning text that could be almost anything.
The cute thing
On Fri, 12 Sep 2003, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Thu, 11 Sep 2003, Bruce Momjian wrote:
Well, the problem was that we defined HAS_TEST_AND_SET inside the ports.
I guess we could splatter a test for Itanium and Opterion in every port
that could possibly use
Marc G. Fournier [EMAIL PROTECTED] writes:
Right, though I am not sure people will know _slow_ configuration vs.
PostgreSQL is slow.
No, but definitely something for those discussion performance to add
to their checklist :)
BTW, post-compile, running system ... how do you check this? Or
Marc G. Fournier wrote:
From what I understand, not working properly means slow, not broken, no?
Which means ppl could submit a problem report and it could be fixed for
v7.4.1 ... its not so much 'not working properly' as it is 'not optimal
performance' ...
Right, though I am not
Subject says it all... if you've got something to get done, now's the
time...
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
Sean Chittenden [EMAIL PROTECTED] writes:
Let me jump in for half a second here (no pun intended), but what
about the use of back quotes? ` `? Use a very limited escaping policy
of \` = ` and \\ = \ .
Actually, having to double backslashes is one of the things I want to
get rid of. The
-On [20030911 15:43], Tom Lane ([EMAIL PROTECTED]) wrote:
We can't ALTER a table that's already in use when the first ALTER
starts, either --- its attempt to exclusive-lock the table will fail.
But once you get the exclusive lock, you can (in Postgres) perform
a series of operations without fear
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Prompted by confusion over Itanium/Opterion, I have written a patch to
improve the way we define spinlocks for platforms and cpu's.
The main.c part of the patch strikes me as irrelevant to the claimed
purpose and unlikely to
Bruce Momjian [EMAIL PROTECTED] writes:
The problem with waiting for 7.5 is that we will have no error reporting
when our non-spinlock code is being executed, and with Opteron/Itanium,
it seems like a good time to get it working.
Well, as long as you're prepared to reduce the list of known
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The problem with waiting for 7.5 is that we will have no error reporting
when our non-spinlock code is being executed, and with Opteron/Itanium,
it seems like a good time to get it working.
Well, as long as you're prepared to reduce
On Thu, 11 Sep 2003, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The problem with waiting for 7.5 is that we will have no error reporting
when our non-spinlock code is being executed, and with Opteron/Itanium,
it seems like a good time to get it working.
Well, as long as
Marc G. Fournier wrote:
But it seems to me that this is mostly a cosmetic cleanup and therefore
not the kind of thing to be doing late in beta. Couldn't we do
something that affects only Opteron/Itanium and doesn't take a chance
on breaking everything else?
I just went through the
--On Thursday, September 11, 2003 23:46:56 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Thu, 11 Sep 2003, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The problem with waiting for 7.5 is that we will have no error
reporting when our non-spinlock code is being executed,
On Thu, 11 Sep 2003, Bruce Momjian wrote:
Yes, but to throw an error if spinlocks aren't found, we need this
patch. We would have to test for Opteron in all the platforms that test
for specific CPU's but don't test for opteron, and might support
opterion/itanium, but even then, we don't
Marc G. Fournier [EMAIL PROTECTED] writes:
On Thu, 11 Sep 2003, Tom Lane wrote:
Well, as long as you're prepared to reduce the list of known supported
platforms to zero as of 7.4beta3, and issue a fresh call for port reports.
I didn't think we had done that yet ... had we? called for port
Bruce Momjian [EMAIL PROTECTED] writes:
I guess we could splatter a test for Itanium and Opterion in every port
that could possibly use it, but then again, if we fall back to not
finding it for some reason, we don't get a report because we silently
fall back to semaphores. That's what has me
Larry Rosenman [EMAIL PROTECTED] writes:
Bruce sent me a copy of the patch, and it BREAKS UnixWare (If y'all=
=20
care).
Unfixably? Or just a small oversight?
I'm actually not worried about platforms that are actively being tested.
It's the stuff that hasn't been confirmed recently
Tom Lane wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
Bruce sent me a copy of the patch, and it BREAKS UnixWare (If y'all=
=20
care).
Unfixably? Or just a small oversight?
I'm actually not worried about platforms that are actively being tested.
It's the stuff that hasn't
--On Thursday, September 11, 2003 23:13:54 -0400 Tom Lane
[EMAIL PROTECTED] wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
Bruce sent me a copy of the patch, and it BREAKS UnixWare (If
y'all= =20
care).
Unfixably? Or just a small oversight?
I'm actually not worried about platforms
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I guess we could splatter a test for Itanium and Opterion in every port
that could possibly use it, but then again, if we fall back to not
finding it for some reason, we don't get a report because we silently
fall back to semaphores.
Bruce Momjian [EMAIL PROTECTED] writes:
Yes, we could do just the configure warning, then plaster tests into the
port files to try to hit all the opteron/itanium cases. I am a little
concerned that this might throw up a bunch of problem cases that we will
patching for a while.
Probably so
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Yes, we could do just the configure warning, then plaster tests into the
port files to try to hit all the opteron/itanium cases. I am a little
concerned that this might throw up a bunch of problem cases that we will
patching for a
Bruce Momjian [EMAIL PROTECTED] writes:
Looking at the code, I wonder if we already have folks not using
spinlocks, and not even knowing it. I don't think problem reports will
be limited to new platforms.
Very likely --- I heard from someone recently who was trying to run
HPUX/Itanium. After
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Looking at the code, I wonder if we already have folks not using
spinlocks, and not even knowing it. I don't think problem reports will
be limited to new platforms.
Very likely --- I heard from someone recently who was trying to
--On Thursday, September 11, 2003 23:42:53 -0400 Tom Lane
[EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Looking at the code, I wonder if we already have folks not using
spinlocks, and not even knowing it. I don't think problem reports will
be limited to new platforms.
Very
Larry Rosenman [EMAIL PROTECTED] writes:
Please, only the first two. Make the Unixware template add __i386__.
Don't add assumptions about valid user-namespace symbols.
that's reasonable. At least until 64-bit UnixWare. :-)
Even then, I'd prefer to put the necessary kluge into
Larry Rosenman [EMAIL PROTECTED] writes:
I've already sent a whine-a-gram to the compiler guys at SCO.
Prolly you thought of this already, but: getting them to *add*
an implicit #define of __i386__ should be plenty easy compared
to getting them to *remove* the one for i386. And while I think
--On Friday, September 12, 2003 00:06:49 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
I've already sent a whine-a-gram to the compiler guys at SCO.
Prolly you thought of this already, but: getting them to *add*
an implicit #define of __i386__ should be
Marc G. Fournier wrote:
On Thu, 11 Sep 2003, Bruce Momjian wrote:
Well, the problem was that we defined HAS_TEST_AND_SET inside the ports.
I guess we could splatter a test for Itanium and Opterion in every port
that could possibly use it, but then again, if we fall back to not
On Thu, 11 Sep 2003, Bruce Momjian wrote:
I just learned from Larry that Unixware defines intel as i386, not
__i386 or __i386__, at least of the native SCO compiler that he uses.
could we put something in the various port files to standardize this? ie.
in unixware.h, add somethinglike:
Marc G. Fournier wrote:
On Thu, 11 Sep 2003, Bruce Momjian wrote:
I just learned from Larry that Unixware defines intel as i386, not
__i386 or __i386__, at least of the native SCO compiler that he uses.
could we put something in the various port files to standardize this? ie.
in
Tom Lane wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
Bruce sent me a copy of the patch, and it BREAKS UnixWare (If y'all=
=20
care).
Unfixably? Or just a small oversight?
Updated patch now works on Unixware.
--
Bruce Momjian|
96 matches
Mail list logo
