If configure sees that the compiler specified by $CC looks like gcc
(defines __GNUC__), then it puts some extra command line options into the
CFLAGS (mostly -W*). The intel C compiler for linux emulates gcc by
default, which means it defines that and looks very much like gcc to
configure.
On Sun, 2 Apr 2006, Peter Eisentraut wrote:
Jeremy Drake wrote:
The intel C compiler for linux emulates gcc
by default, which means it defines that and looks very much like gcc
to configure. However, it does not get along with the added -W flags
very well. They don't seem to kill
On Sat, 22 Apr 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
On Fri, 21 Apr 2006, Tom Lane wrote:
Yeah. NaN == 0 is just silly ...
From what I can tell from the instruction set docs and test programs, the
actual bug/misoptimization is that NaN == anything. Which is even
On Sun, 2 Jul 2006, Tom Lane wrote:
Nah, it was a false alarm: I was looking at the first post-patch report,
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mongoosedt=2006-07-02%2003:30:01
but apparently mongoose had managed to pick up a partially-updated
snapshot. The later reports
I put together a patch which adds a regression test for large objects,
hopefully attached to this message. I would like some critique of it, to
see if I have gone about it the right way. Also I would be happy to hear
any additional tests which should be added to it.
On Tue, 5 Sep 2006, Jeremy
On Thu, 21 Sep 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
I put together a patch which adds a regression test for large objects,
hopefully attached to this message. I would like some critique of it, to
see if I have gone about it the right way. Also I would be happy
On Sun, 24 Sep 2006, Jeremy Drake wrote:
On Thu, 21 Sep 2006, Tom Lane wrote:
I suggest that instead of testing the server-side lo_import/lo_export
functions, perhaps you could test the psql equivalents and write and
read a file in psql's working directory.
I did not see any precedent
On Mon, 25 Sep 2006, Jeremy Drake wrote:
It looks like the large_obj.c output is missing much of the output
settings handling which is in the PrintQueryStatus function in common.c,
such as handling quiet mode, and html output. I will try to dig around
and try to put together a patch to make
On Sun, 24 Sep 2006, Jeremy Drake wrote:
On Thu, 21 Sep 2006, Tom Lane wrote:
I think we could do without the Moby Dick extract too ...
I am open to suggestions. I saw one suggestion that I use an image of an
elephant, but I suspect that was tongue-in-cheek. I am not very fond
This is the latest version of the large object regression test I have been
working on. Note that a prerequisite for this version of the test is the
patch I made to psql to make it not output on \lo_* commands in quiet mode
is required (also attached, it's small).
Sorry that it still makes use of
I sent this in a while back, but never heard anything about it.
This patch makes psql's \lo_* commands respect the -q flag (or other
methods of setting quiet mode) as well as HTML output mode. This came in
very handy when writing a regression test which uses the \lo_import
command since it would
for independant consideration. I'll save my pushing on the
large object test until this one gets in ;)
-- Forwarded message --
Date: Thu, 26 Oct 2006 15:58:07 -0700 (PDT)
From: Jeremy Drake [EMAIL PROTECTED]
To: PostgreSQL Patches pgsql-patches@postgresql.org
Subject: [PATCHES
Given the recent changes to the regression scripts, the large object
regression test patch I submitted quite a while ago, and is currently in
the patch hold queue, no longer cleanly applies. This patch is
functionally the same as the last one, but cleanly applies to current CVS
head.
Note that
Oops, that patch did not actually apply cleanly. Try this one instead,
it should. Please disregard the previous copy. Sorry.
On Fri, 19 Jan 2007, Jeremy Drake wrote:
Given the recent changes to the regression scripts, the large object
regression test patch I submitted quite a while ago
On Wed, 24 Jan 2007, Jeremy Drake wrote:
On Wed, 24 Jan 2007, Martijn van Oosterhout wrote:
Something I've wondered about before is the concept of having installed
Modules in the system. Let's say for example that while compiling
postgres it compiled the modules in contrib also
On Wed, 24 Jan 2007, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
On Wed, 24 Jan 2007, Jeremy Drake wrote:
That would be great, and also it would be great to be able to CREATE
LANGUAGE as a regular user for a trusted pl that is already
compiled/installed.
Something like
On Wed, 24 Jan 2007, Tom Lane wrote:
Not the DB owner. If you are worried about whether to allow use of PLs
it's almost certainly an installation-wide security concern, so I'd say
that the privilege has to flow from a superuser.
GRANT CREATE ON LANGUAGE feeding into a flag bit in pltemplate
On Wed, 24 Jan 2007, Tom Lane wrote:
In detail, it'd look something like:
* For an untrusted language: must be superuser to either create or use
the language (no change from current rules). Ownership of the
pg_language entry is really irrelevant, as is its ACL.
* For a trusted language:
On Wed, 24 Jan 2007, Jeremy Drake wrote:
On Wed, 24 Jan 2007, Tom Lane wrote:
In detail, it'd look something like:
* For an untrusted language: must be superuser to either create or use
the language (no change from current rules). Ownership of the
pg_language entry is really
On Thu, 25 Jan 2007, Jeremy Drake wrote:
On Thu, 25 Jan 2007, Jeremy Drake wrote:
I think that an ALTER LANGUAGE OWNER TO is the proper response to these
things, and unless I hear otherwise I will attempt to add this to my
patch.
Here is the patch which adds this. It also allows ALTER
On Sat, 27 Jan 2007, Tom Lane wrote:
I'd go with GetUserId() in the cases where you're not explicitly
assigning ownership to the datdba role. AFAIR the assumption that
languages are owned by BOOTSTRAP_SUPERUSERID was just a kluge to use in
some bits of code that had to have a notion of a
This version of the patch includes documentation changes. Please
review...
--
The more things change, the more they stay insane.Index: doc/src/sgml/catalogs.sgml
===
RCS file:
On Sun, 4 Feb 2007, David Fetter wrote:
On Fri, Feb 02, 2007 at 07:01:33PM -0800, Jeremy Drake wrote:
Let me know if you see any bugs or issues with this code, and I am
open to suggestions for further regression tests ;)
Things that I still want to look into:
* regexp flags (a la
On Wed, 7 Feb 2007, David Fetter wrote:
On Wed, Feb 07, 2007 at 09:23:58AM -0500, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
* Put together a patch to add these functions to core. I could put them
directly in regexp.c, so the support functions could stay static. My
directories; pg_regress would take care to generate the
files as needed.
It Just Worked with the changes made to pg-regress to support the other,
similar tests (ie, copy).
---
Jeremy Drake wrote:
This is the latest version
On Wed, 7 Feb 2007, Jeremy Drake wrote:
Here is a patch to add these functions to core. Please take a look and
let me know what you think. I had to jump through a bit of a hoop to
avoid opr_sanity test from breaking, may not have done that right.
Also, this patch allows regexp_replace
applied.
---
Jeremy Drake wrote:
I sent this in a while back, but never heard anything about it.
This patch makes psql's \lo_* commands respect the -q flag (or other
methods of setting quiet mode) as well as HTML
What was the status of this? Was there anything else I needed to do with
this patch, or is it ready to be applied? Let me know if there is
anything else I need to do on this...
--
What this country needs is a good five cent nickel.
---(end of
On Thu, 15 Feb 2007, Peter Eisentraut wrote:
Neil Conway wrote:
On Wed, 2007-02-14 at 16:49 -0800, Jeremy Drake wrote:
What was the status of this? Was there anything else I needed to
do with this patch, or is it ready to be applied? Let me know if
there is anything else I need
On Thu, 15 Feb 2007, Alvaro Herrera wrote:
Jeremy Drake wrote:
The functions added are:
* regexp_split(str text, pattern text) RETURNS SETOF text
regexp_split(str text, pattern text, flags text) RETURNS SETOF text
returns each section of the string delimited by the pattern
On Fri, 16 Feb 2007, Peter Eisentraut wrote:
Am Freitag, 16. Februar 2007 08:02 schrieb Jeremy Drake:
Does this version sufficiently address your concerns?
I don't think anyone asked for the start position and length in the result of
regexp_split(). The result should be an array of text
On Sat, 17 Feb 2007, Peter Eisentraut wrote:
Jeremy Drake wrote:
In case you haven't noticed, I am rather averse to making this return
text[] because it is much easier in my experience to use the results
when returned in SETOF rather than text[],
The primary use case I know for string
Finally the voice of reason :)
On Sat, 17 Feb 2007, Tom Lane wrote:
So I'd vote against complicating the API in order to make special
provision for these results. I claim that all we need is a function
taking (string text, pattern text, flags text) and returning either
array of text or setof
On Sat, 17 Feb 2007, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
On Sat, 17 Feb 2007, Tom Lane wrote:
So I'd vote against complicating the API in order to make special
provision for these results. I claim that all we need is a function
taking (string text, pattern text, flags
On Sun, 18 Feb 2007, Jeremy Drake wrote:
On Sun, 18 Feb 2007, Peter Eisentraut wrote:
regexp_split(string text, pattern text[, flags text]) returns setof
text
regexp_split_array(string text, pattern text[. flags text[, limit
int]]) returns text[]
Since you are not splitting
that is correct.
It would be good if someone more knowledgeable about such things checked
on this when applying it...
The latest version of the patch is currently at
http://momjian.us/mhonarc/patches/msg00014.html
---
Jeremy Drake
Since I have now learned that it is possible to input values in hex in
postgres, I submit this patch to clean up the ugly workaround I did in the
largeobject regression test to try to input hex values. It does not
change the functionality of the test at all, it just makes it more
readable.
In
.
---
Jeremy Drake wrote:
Since I have now learned that it is possible to input values in hex in
postgres, I submit this patch to clean up the ugly workaround I did in the
largeobject regression test to try to input hex values. It does not
change the functionality
On Wed, 21 Mar 2007, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
* Comments like /* get text type oid, too lazy to do it some other way
*/ do not exactly inspire confidence :)
Surely the code was just using the TEXTOID macro? If so, it does not
require a comment. If not, it
On Wed, 21 Mar 2007, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
BTW, should I be calling
get_typlenbyvalalign on TEXTOID or are there macros for those also?
By and large we tend to hard-wire those properties too, eg there are
plenty of places that do things like
On Wed, 21 Mar 2007, Gregory Stark wrote:
The only thing I would say is that this should maybe be a TextGetDatum() just
for code hygiene. It should be exactly equivalent though:
I could not find such a thing using ctags, nor TextPGetDatum(). I looked
at PG_RETURN_TEXT_P and it just uses
On Thu, 22 Mar 2007, Tom Lane wrote:
I'd vote for making this new code look like the rest of it, to wit
hardwire the values.
Attached please find a patch which does this.
--
Although written many years ago, Lady Chatterley's Lover has just been
reissued by the Grove Press, and this
On Thu, 22 Mar 2007, Tom Lane wrote:
AFAIR, the reason there's no TextPGetDatum (and ditto for lots of other
datatypes) is lack of obvious usefulness. A function dealing with a
text * doesn't normally have reason to convert that to a Datum until
it returns --- and at that point
On Mon, 26 Mar 2007, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
This version of the patch includes documentation changes. Please
review...
Applied with minor revisions --- in particular, I thought the initial
owner of a language should be its creator, full stop, rather than
On Mon, 26 Mar 2007, Bruce Momjian wrote:
Tom Lane wrote:
Or were you speaking to the question of whether to adjust the regexp
patch to conform more nearly to the coding practices found elsewhere?
I agree with that, but I thought there was already a submitted patch
for it.
Yes, regex
Jeremy Drake wrote:
On Thu, 22 Mar 2007, Tom Lane wrote:
I'd vote for making this new code look like the rest of it, to wit
hardwire the values.
Attached please find a patch which does this.
I just realized that the last patch removed all usage of fcinfo in the
setup_regexp_matches
On Wed, 28 Nov 2007, Alvaro Herrera wrote:
David Fetter wrote:
Greg Sabino Mullane managed to contrive an example where RULEs might
conceivably be the least-bad way to do this, that being a machine
where no PLs may be installed.
Perhaps this just means we should consider installing
On Fri, 14 Mar 2008, ITAGAKI Takahiro wrote:
DWORD is an alias for 'unsigned long' in 32bit Windows.
Do you know how it defined in 64bit Windows?
sizeof(DWORD) is always 4, even on 64-bit windows. sizeof(long) is also
always 4. If you want the unsigned integral type that is the same size as
48 matches
Mail list logo
