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
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.
---
Jeremy Drake wrote:
I just realized that the last patch removed all usage of fcinfo in the
setup_regexp_matches function, so this version of the patch also removes
it as a parameter to that function.
Applied, thanks.
-Neil
---(end of
Jeremy Drake wrote:
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
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.
---
Jeremy Drake wrote:
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
Bruce Momjian [EMAIL PROTECTED] writes:
Jeremy Drake wrote:
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.
If you are asking why I have reason to convert text * to a Datum in cases
other
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Jeremy Drake wrote:
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.
If you are asking why I have reason to convert text * to a
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 [EMAIL PROTECTED] writes:
BTW, should I be calling get_typlenbyvalalign on TEXTOID or are there macros
for those also?
Hardcoding -1 for typlen of varlenas is one of the few (the only?) magic
constants used throughout the source code. I'm surprised there isn't a macro
for it
Gregory Stark [EMAIL PROTECTED] writes:
Jeremy Drake [EMAIL PROTECTED] writes:
BTW, should I be calling get_typlenbyvalalign on TEXTOID or are there macros
for those also?
Hardcoding -1 for typlen of varlenas is one of the few (the only?) magic
constants used throughout the source code.
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 this:
/* XXX: this hardcodes assumptions about the
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 this:
/*
Jeremy Drake [EMAIL PROTECTED] writes:
On Wed, 21 Mar 2007, Tom Lane wrote:
By and large we tend to hard-wire those properties too, eg there are
plenty of places that do things like this:
So, what action (if any) should be taken? Should all (or some) of these
values be hardcoded, or should
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
Jeremy Drake [EMAIL PROTECTED] writes:
I could not find such a thing using ctags, nor TextPGetDatum(). I looked
at PG_RETURN_TEXT_P and it just uses PG_RETURN_POINTER, which in turn uses
PointerGetDatum. If there is such a thing, it is well camoflaged...
AFAIR, the reason there's no
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
Jeremy Drake wrote:
The patch has been sitting in the unapplied patches queue for a while, and
the inevitable bitrot finally caught up with it. This version of the
patch is exactly the same as the one in the patches queue, except for
using new, non-conflicting oids for the functions.
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 should be fixed ...
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
Jeremy Drake wrote:
The patch has been sitting in the unapplied patches queue for a while
Barring any objections, I'll apply this tomorrow.
-Neil
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
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.
---
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_split(string text, pattern text[, flags text]) returns setof
text
regexp_split_array(string text, pattern text[.
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
Jeremy Drake [EMAIL PROTECTED] writes:
I will rename the functions regexp_split_to_(table|array) and I will add
an optional limit parameter to the regexp_split_to_table function, for
consistency and to avoid ordering concerns with LIMIT.
I'd go the other way: get rid of the limit option all
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 splitting is parsing
comma/pipe/whatever separated
On Sat, Feb 17, 2007 at 09:02:24AM +0100, 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
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
David Fetter wrote:
What is it about having the whole match, pre-match and post-match
available that you're objecting to? Are you saying there aren't
common uses for any or all of these? Regular expression users use
them all over the place,
You keep saying that, and I keep saying please
Peter Eisentraut [EMAIL PROTECTED] writes:
David Fetter wrote:
What is it about having the whole match, pre-match and post-match
available that you're objecting to? Are you saying there aren't
common uses for any or all of these? Regular expression users use
them all over the place,
You
Jeremy Drake wrote:
For this case see string_to_array:
That only works with fixed delimiters, and I was hoping that
regexp_split would be an alternative with regexp delimiters. It's
certainly another argument that all the split functions in PostgreSQL
should offer analogous interfaces.
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
Jeremy Drake wrote:
The regexp_split function code was based on some code that a friend of
mine wrote which used PCRE rather than postgres' internal regexp support.
I don't know exactly what his use-case was, but he probably had
one because he wrote the function and had it returning SETOF text
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 text) and returning either
array of text
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
Am Freitag, 16. Februar 2007 08:02 schrieb Jeremy Drake:
On Thu, 15 Feb 2007, Peter Eisentraut wrote:
I have no strong opinion about how matches are returned. Seeing the
definitional difficulties that you point out, it may be fine to return
them unordered. But then all matches functions
On Fri, Feb 16, 2007 at 05:54:47PM +0100, Peter Eisentraut wrote:
Am Freitag, 16. Februar 2007 17:11 schrieb David Fetter:
As for the regexp_matches() function, it seems to me that it
returns too much information at once. What is the use case for
getting all of prematch, fullmatch,
David Fetter wrote:
The question is, what is the use case? If there is one in Perl, can
this proposed function API support it?
Perl makes the following variables available in any regex match,
although it optimizes some cases for when they're not there:
$1, ... $n (captured matches in
David Fetter wrote:
The question is, what is the use case? If there is one in Perl,
can this proposed function API support it?
Perl makes the following variables available in any regex match,
That is not a use case.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
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.
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 to do on this...
Will do -- I'm planning to apply
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 to
Jeremy Drake wrote:
regexp_matches uses a text[] for the match groups. If you specify
the global flag, it could return multiple matches. Couple this with
the requested feature of pre- and postmatch returns (with its own
flag) and the return would turn into some sort of nasty array of
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.
* regexp_matches(str text, pattern text) RETURNS text[]
Peter Eisentraut [EMAIL PROTECTED] writes:
Jeremy Drake wrote:
# My experience with the array code leads me to believe that building
up an array is an expensive proposition. I know I could code it
smarter so that the array is only constructed in the end.
You can make any code arbitrarily
Alvaro Herrera [EMAIL PROTECTED] writes:
so that you would have the position for each match, automatically. Is
this information available in the regex code?
Certainly, that's where we got the text snippets from to begin with.
However, I'm not sure that this is important enough to justify a
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
so that you would have the position for each match, automatically. Is
this information available in the regex code?
Certainly, that's where we got the text snippets from to begin with.
However, I'm not sure that this is important
Alvaro Herrera wrote:
On the other hand, I don't think it's impossible to have matches that
start earlier than others in the string, but are actually found later
(say, because they are a parentized expression that ends later). So
giving the starting positions allows one to know where are they
On Thu, Feb 15, 2007 at 10:37:26AM -0500, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
so that you would have the position for each match, automatically. Is
this information available in the regex code?
Certainly, that's where we got the text snippets from to begin with.
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.
*
David Fetter [EMAIL PROTECTED] writes:
I've obviously misunderstood the scope of the TODO because it appears
that an INSERT into pg_type at creation time for compound types that
looks something like the below would do it. What have I missed?
There are a couple of issues. One is that we
On Thu, Feb 15, 2007 at 07:35:46PM -0500, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
I've obviously misunderstood the scope of the TODO because it appears
that an INSERT into pg_type at creation time for compound types that
looks something like the below would do it. What have
Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
I've obviously misunderstood the scope of the TODO because it appears
that an INSERT into pg_type at creation time for compound types that
looks something like the below would do it. What have I missed?
There are a couple of
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 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 to do on this...
Will do -- I'm planning to apply this as soon as I have the
On Fri, 2007-02-09 at 01:08 -0800, Jeremy Drake wrote:
Yeah, I try to do that, but this one just barely passed my personal
compression threshold. Guess I should raise my threshold :)
No, don't pay any attention to me, I'm just lazy :)
Here is a new version of the patch which fixes up the
On Fri, 2007-02-09 at 16:33 -0800, Jeremy Drake wrote:
Here is a new version of the patch which eliminates the doing_srf stuff.
* C89 require constant-sized stack allocated arrays, so the coding in
perform_regexp_matches() is non-portable.
* I'm not clear about the control flow in
On Thu, 2007-02-08 at 19:22 -0800, Jeremy Drake wrote:
I have added documentation for the functions in this patch. At this point
I am ready to submit this patch for the review and application process.
Please let me know if you find any issues with it.
Barring any objections, I'll review and
Neil Conway wrote:
BTW, unless the patch is truly large, leaving the patch uncompressed
makes it easier to eyeball it without leaving my mail client. That's
just personal preference, though...
FWIW, I just do a | zcat | less, which shows it uncompressed. No big
deal. I don't know if
Alvaro Herrera wrote:
Neil Conway wrote:
BTW, unless the patch is truly large, leaving the patch uncompressed
makes it easier to eyeball it without leaving my mail client. That's
just personal preference, though...
FWIW, I just do a | zcat | less, which shows it uncompressed. No big
61 matches
Mail list logo
