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
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 instal
> 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
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.
>
> Ye
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 sh
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 PG_RETUR
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 pictor
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 PG_R
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 p
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
others.
> ---
>
>
> 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
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 det
onarc/patches/msg00014.html
> -------
>
>
> Jeremy Drake wrote:
> > 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
> >
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
On Sun, 18 Feb 2007, Peter Eisentraut wrote:
> Jeremy Drake wrote:
> > > As for the argument about array vs setof, I could see doing both to
> > > end the argument of which one is really superior for any particular
> > > problem.
> >
> > regexp_sp
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
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 se
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[],
>
>
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 resul
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
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
&
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 broadcast)-
one has also already been applied.
>
> -------
>
>
> Jeremy Drake wrote:
> > I sent this in a while back, but never heard anything about it.
> >
> > This patch makes psql's \lo_* commands resp
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
input,
> output or data 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).
>
> > -------
&g
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 su
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 lo
On Fri, 2 Feb 2007, David Fetter wrote:
> On Fri, Feb 02, 2007 at 08:56:31PM -0500, Tom Lane wrote:
> >
> > All of SQL's pattern match operators have the pattern on the right,
> > so my advice is to stick with that and try not to think about Perl
> > ;-)
>
> Perl provides inspiration, but here, co
On Thu, 1 Feb 2007, Jeremy Drake wrote:
> On Thu, 1 Feb 2007, Tom Lane wrote:
>
> > Jeremy Drake <[EMAIL PROTECTED]> writes:
> > > Is there some specific reason that these functions are static,
> >
> > Yeah: not cluttering the global namespace.
>
>
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:
/data/local/jeremyd/postgres/cvsuproot/pgsql/doc/src/s
On Fri, 26 Jan 2007, Jeremy Drake wrote:
> 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_SUPE
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
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 p
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 LANGUAGE RENAME
TO for the owner
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). Owners
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 langu
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 pltemp
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 i
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 co
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 whi
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 th
seperately 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
Subject: [PATCHES] psql \
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
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
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.
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 toge
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 dir
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
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 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=mongoose&dt=2006-07-02%2003:30:01
> but apparently mongoose had managed to pick up a partially-updated
> snapshot. The later reports (
On Sat, 22 Apr 2006, Tom Lane wrote:
> Given that we've already got a test for ICC in there as of today, I'd
> vote for adding -mp1 to CFLAGS if we see it's ICC.
This patch seems to do the trick...
Index: configure.in
===
RCS file:
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/
On Fri, 21 Apr 2006, Tom Lane wrote:
> Bruce Momjian writes:
> > This seems like a compiler bug so I am hoping it will be fixed, or is
> > already fixed in a later release.
>
> Yeah. NaN == 0 is just silly ...
>From what I can tell from the instruction set docs and test programs, the
actual bug
an unordered result, like this:
comisd 0, NaN
jp nequal
je equal
nequal:
; false
equal:
; true
On Fri, 21 Apr 2006, Bruce Momjian wrote:
>
> Comment added and patch applied. Thanks.
>
> ---
>
>
&g
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
> > ver
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. However
56 matches
Mail list logo
