scott.marlowe wrote:
On Sun, 23 Mar 2003, Kevin Brown wrote:
Use "split" and "merge". Avoids the "join" issue and avoids the
"implode/explode" issue too. :-)
Isn't merge a new SQL keyword in SQL99 or SQL03?
Yup, in SQL200x at least:
14.9
Function
Conditionally update rows of a table, or insert
On Sun, 23 Mar 2003, Kevin Brown wrote:
> Joe Conway wrote:
> > Jason Earl wrote:
> > >>Actually, I think it was someone else (Joe???) that is doing the leg
> > >>work, and he was the one choosing explode / implode and getting
> > >>gruff for it, so I was just stepping in and defending his decisio
Joe Conway wrote:
> Jason Earl wrote:
> >>Actually, I think it was someone else (Joe???) that is doing the leg
> >>work, and he was the one choosing explode / implode and getting
> >>gruff for it, so I was just stepping in and defending his decision.
> >
> >Oops, my bad. My brain must already thin
Jason Earl wrote:
Actually, I think it was someone else (Joe???) that is doing the leg
work, and he was the one choosing explode / implode and getting
gruff for it, so I was just stepping in and defending his decision.
Oops, my bad. My brain must already think that it is the weekend. My
reasoning
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> On 14 Mar 2003, Jason Earl wrote:
>
> > It's all good Scott. Anyone wanting to use PostgreSQL arrays
> > would undoubtedly open up the corresponding part of the manual
> > that covers array functions. Since there is likely to be less
> > than a page
On 14 Mar 2003, Jason Earl wrote:
> It's all good Scott. Anyone wanting to use PostgreSQL arrays would
> undoubtedly open up the corresponding part of the manual that covers
> array functions. Since there is likely to be less than a page full of
> function definitions you could probably call the
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> On Fri, 14 Mar 2003, Þórhallur Hálfdánarson wrote:
>
> > -*- Greg Stark <[EMAIL PROTECTED]> [ 2003-03-14 17:43 ]:
> > > Do you really think someone looking for a function to break up a string into a
> > > list of strings would ever think of looking up
On Fri, 14 Mar 2003, D'Arcy J.M. Cain wrote:
> On Friday 14 March 2003 13:24, scott.marlowe wrote:
> > I vote for explode / implode as easier to type and remember than join_str.
> > Also, in the SQL world, it's very likely that a back ground in
> > ADA/LISP/REX/PHP is just as common as Perl or Jav
Here's a list of synonyms for join (courtesy of m-w.com):
associate, bracket, coadunate, coagment, coalesce, combine, compound,
concrete, conjoin, conjugate, connect, couple, link, marry, one, relate,
unite, wed, yoke
and for split:
carve, cleave, dissect, dissever, sever, slice, sunder, cleave
On Friday 14 March 2003 13:24, scott.marlowe wrote:
> I vote for explode / implode as easier to type and remember than join_str.
> Also, in the SQL world, it's very likely that a back ground in
> ADA/LISP/REX/PHP is just as common as Perl or Java.
If we're voting I vote for join/split. Implode an
On Fri, 14 Mar 2003, Þórhallur Hálfdánarson wrote:
> -*- Greg Stark <[EMAIL PROTECTED]> [ 2003-03-14 17:43 ]:
> > Do you really think someone looking for a function to break up a string into a
> > list of strings would ever think of looking up "explode" in an index if he
> > hadn't already used PH
On Fri, 14 Mar 2003, Christopher Browne wrote:
> > Do you really think someone looking for a function to break up a
> > string into a list of strings would ever think of looking up "explode"
> > in an index if he hadn't already used PHP or (shudder) VBScript?
>
> It's also one of the classic exam
-*- Greg Stark <[EMAIL PROTECTED]> [ 2003-03-14 17:43 ]:
> Do you really think someone looking for a function to break up a string into a
> list of strings would ever think of looking up "explode" in an index if he
> hadn't already used PHP or (shudder) VBScript?
If one had gotten used to Lotus No
> Do you really think someone looking for a function to break up a
> string into a list of strings would ever think of looking up "explode"
> in an index if he hadn't already used PHP or (shudder) VBScript?
It's also one of the classic examples of things used in introductory
courses on Lisp that a
On 14 Mar 2003, Greg Stark wrote:
>
> "scott.marlowe" <[EMAIL PROTECTED]> writes:
>
> > You're quick to throw out a trollish barb against PHP without any
> > real discussion as to why it's such a horrible language.
>
> No need to be so sensitive. It was just a humorous way of making the poin
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> You're quick to throw out a trollish barb against PHP without any
> real discussion as to why it's such a horrible language.
No need to be so sensitive. It was just a humorous way of making the point
that just because PHP does something doesn't me
On 13 Mar 2003, Greg Stark wrote:
>
> Joe Conway <[EMAIL PROTECTED]> writes:
>
> > I'm leaning toward implode() and explode() now anyway because split() uses a
> > regex for the delimiter in PHP (and probably Perl), and I was not planning to
> > get that fancy.
>
> PHP isn't exactly an exemplar
> implode(text[], text) returns text - join array elements into a
> string using given string delimiter
>
> I'm open to opinions on implode() -- I only picked implode() because
> that's what it is called in PHP. Any suggestions?
It's also called 'join' in PHP...
Chris
---
Joe Conway <[EMAIL PROTECTED]> writes:
> I'm leaning toward implode() and explode() now anyway because split() uses a
> regex for the delimiter in PHP (and probably Perl), and I was not planning to
> get that fancy.
PHP isn't exactly an exemplar for great language design.
explode/implode are te
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Hmmm -- I doubt that would fly, although I see it is specifically
allowed as a function name (func_name_keyword list). Anyone have
opinions on this either way?
Good point --- it would work today, but any small tweak in the JOIN
grammar might
Joe Conway <[EMAIL PROTECTED]> writes:
>> In both Perl and Python, that type of function is called "join".
> Hmmm -- I doubt that would fly, although I see it is specifically
> allowed as a function name (func_name_keyword list). Anyone have
> opinions on this either way?
Good point --- it woul
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Tom Lane kirjutas N, 13.03.2003 kell 19:12:
>>> The standard spelling for that appears to be
>>> somearray || ARRAY[element]
>>> which also has the nice property that it is commutative.
>>
>> Sure ... but that just means that || is the operator name for
Tom Lane kirjutas N, 13.03.2003 kell 19:12:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > OK, let's look at these more closely:
>
> >> array_push(anyarray, anyelement) returns anyarray
>
> > The standard spelling for that appears to be
> > somearray || ARRAY[element]
> > which also has t
On Thu, 2003-03-13 at 12:53, Joe Conway wrote:
> Peter Eisentraut wrote:
> array_pop(anyarray) returns anyelement
> >
> > That appears to mean that you return somearray[0] and alter the array
> > as a side effect. How do you plan to do that?
>
> I'll give you this one -- doesn't make sense.
Alvaro Herrera wrote:
Yeah, and join is also consistent with the inverse function being called
"split". IIRC the equivalent function in PHP is explode().
Actually it looks like PHP supports both explode() and split(), and
their inverse functions implode() and join(). split() appears to split
the
johnn wrote:
On Thu, Mar 13, 2003 at 09:53:15AM -0800, Joe Conway wrote:
implode(text[], text) returns text - join array elements into a
string using given string delimiter
In both Perl and Python, that type of function is called "join".
Hmmm -- I doubt that would fly, although I see it is spec
On Thu, Mar 13, 2003 at 12:00:46PM -0600, johnn wrote:
> On Thu, Mar 13, 2003 at 09:53:15AM -0800, Joe Conway wrote:
> > implode(text[], text) returns text - join array elements into a
> > string using given string delimiter
> >
> > I'm open to opinions on implode() -- I only picked im
On Thu, Mar 13, 2003 at 09:53:15AM -0800, Joe Conway wrote:
> implode(text[], text) returns text - join array elements into a
> string using given string delimiter
>
> I'm open to opinions on implode() -- I only picked implode() because
> that's what it is called in PHP. Any suggestions?
Peter Eisentraut wrote:
array_pop(anyarray) returns anyelement
That appears to mean that you return somearray[0] and alter the array
as a side effect. How do you plan to do that?
I'll give you this one -- doesn't make sense.
split(text, text) returns text[] - split string into array on
delimiter
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> OK, let's look at these more closely:
>> array_push(anyarray, anyelement) returns anyarray
> The standard spelling for that appears to be
> somearray || ARRAY[element]
> which also has the nice property that it is commutative.
Sure ... but that
OK, let's look at these more closely:
> >> array_push(anyarray, anyelement) returns anyarray
The standard spelling for that appears to be
somearray || ARRAY[element]
which also has the nice property that it is commutative.
> >> array_pop(anyarray) returns anyelement
That appears
Joe Conway <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> Create an array support package on gborg if you like, but I feel this
>> should not be in the mainline.
> Arrays *do* have a place, and they are supported in SQL99+.
FWIW, I'm with Joe on this one. Arrays have their uses; and it
Peter Eisentraut wrote:
> Joe Conway writes:
>
>>2) Implement the following new builtin functions
>> array_push(anyarray, anyelement) returns anyarray
>> array_pop(anyarray) returns anyelement
>> array_subscript(anyarray, int) yields anyelement
>> singleton_array(anyelement) ret
Joe Conway writes:
> 2) Implement the following new builtin functions
> array_push(anyarray, anyelement) returns anyarray
> array_pop(anyarray) returns anyelement
> array_subscript(anyarray, int) yields anyelement
> singleton_array(anyelement) returns anyarray
> -
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
+ * If ANY, ANYARRAY, or ANYELEMENT is used for a function's arguments or
+ * return type, make sure the runtime types are consistent with
+ * each other. The argument consistency rules are like so:
Hmm. I don't see why we should drag ANY i
Joe Conway <[EMAIL PROTECTED]> writes:
> + * If ANY, ANYARRAY, or ANYELEMENT is used for a function's arguments or
> + * return type, make sure the runtime types are consistent with
> + * each other. The argument consistency rules are like so:
> + *
> + * 1) All arguments declared ANY should h
Tom Lane wrote:
But I think I like better the notion of extending my bound-together-
ANYARRAY-and-ANYELEMENT proposal,
http://archives.postgresql.org/pgsql-hackers/2003-03/msg00319.php
Suppose that we do that, and then further say that ANYARRAY or
ANYELEMENT appearing as the return type implies tha
> So if I understand correctly, all instances of anyarray and anyelement
> in a function definition would need to be self-consistent, but the group
> could represent essentially any datatype with its corresponding array
> type. If we need more than one of these self consistent groups, we could
Joe Conway <[EMAIL PROTECTED]> writes:
> So if I understand correctly, all instances of anyarray and anyelement
> in a function definition would need to be self-consistent, but the group
> could represent essentially any datatype with its corresponding array
> type. If we need more than one of t
On Mon, Mar 10, 2003 at 09:49:47AM -0500, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Joe Conway kirjutas E, 10.03.2003 kell 05:35:
> >> CREATE OR REPLACE FUNCTION array_push (anyarray, anyscalar)
> >> RETURNS anyarray
>
> > could you make it
> > RETURNS typeof($1)
>
> Not dir
Tom Lane wrote:
But I think I like better the notion of extending my bound-together-
ANYARRAY-and-ANYELEMENT proposal,
http://archives.postgresql.org/pgsql-hackers/2003-03/msg00319.php
Suppose that we do that, and then further say that ANYARRAY or
ANYELEMENT appearing as the return type implies tha
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Joe Conway kirjutas E, 10.03.2003 kell 05:35:
>> CREATE OR REPLACE FUNCTION array_push (anyarray, anyscalar)
>> RETURNS anyarray
> could you make it
> RETURNS typeof($1)
Not directly --- we have to fit the return-type info into an OID field.
We could fa
Joe Conway kirjutas E, 10.03.2003 kell 05:35:
> CREATE OR REPLACE FUNCTION array_push (anyarray, anyscalar)
> RETURNS anyarray
> AS '$libdir/plr','array_push'
> LANGUAGE 'C';
could you make it
RETURNS typeof($1)
?
--
Hannu
---(end of broadcast)---
Joe Conway <[EMAIL PROTECTED]> writes:
> It seems that "any" is not accepted as a function parameter type.
You have to double-quote it.
We could perhaps rename it to avoid the keyword conflict; I'd lean
towards "anytype" if we do ("anyscalar" seems misleading; I'd expect
that to exclude arrays).
Tom Lane wrote:
I played with generalizing array functions a bit for plr and ran into
some problems (which I can't specifically recall at the moment), but
clearly that's the way to go. I'll start playing with your suggestions
in C code, and report back for more feedback as it solidifies.
It'd be
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It would take some hackery to propagate the destination type down into
>> the ARRAY[] before the latter's type resolution is done, but at least
>> it'd be a quite localized hack.
> OK -- I'll try to make that work. I presume that in the n
Tom Lane wrote:
By analogy to the "type 'literal'" syntax? I'd prefer not to go that
route, because that syntax for literals is a horrid kluge --- to keep
bison from spitting up, we've had to put a bunch of nasty restrictions
on the type names that can appear in such constructs. All those
restric
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The array type is determined how? I'd like this syntax better if there
>> were a way to force the choice of array type...
> What about:
> select integer ARRAY[1,2,3];
> result '{1,2,3}'::integer[]
By analogy to the "type 'literal'"
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
select ARRAY[1,2,3];
result '{1,2,3}'
The array type is determined how? I'd like this syntax better if there
were a way to force the choice of array type...
What about:
select integer ARRAY[1,2,3];
result '{1,2,3}'::integer[]
select ARRAY
Joe Conway <[EMAIL PROTECTED]> writes:
> select ARRAY[1,2,3];
>result '{1,2,3}'
The array type is determined how? I'd like this syntax better if there
were a way to force the choice of array type...
> select ARRAY[(select oid from pg_class order by relname)];
>result is array of all the
I'd like to implement SQL99/200x ARRAY support (well, at least the
basics). Does anyone have objections to the following grammar/semantics?
===
Per SQL200x - examples
===
create table f
51 matches
Mail list logo
