On Wed, Dec 23, 2009 at 1:44 AM, Craig Ringer
wrote:
> SELECT COALESCE( t_number::text, t:string::text, t_date::text,
> t_boolean::text) AS value;
Your invocation of COALESCE is incorrect -- it is n-ary, but it
returns its first non-NULL argument. Instead, try:
SELECT
COALESCE(t_number::te
2009/12/23 Ivan Sergio Borgonovo :
> On Wed, 23 Dec 2009 11:36:31 -0500
> Tom Lane wrote:
>
>> Craig Ringer writes:
>> > Pavel Stehule wrote:
>> >> these queries are executed in some special mode, but still it
>> >> is more expensive than C a = a + 1
>>
>> > ... and may have different rules, so y
On Wed, 23 Dec 2009 11:36:31 -0500
Tom Lane wrote:
> Craig Ringer writes:
> > Pavel Stehule wrote:
> >> these queries are executed in some special mode, but still it
> >> is more expensive than C a = a + 1
>
> > ... and may have different rules, so you can't just write a
> > simple "map express
Craig Ringer writes:
> Pavel Stehule wrote:
>> these queries are executed in some special mode, but still it is more
>> expensive than C a = a + 1
> ... and may have different rules, so you can't just write a simple "map
> expressions to C equivalents" arithmetic evaluator.
Yeah. As an example,
2009/12/23 Ivan Sergio Borgonovo :
> On Wed, 23 Dec 2009 14:35:27 +0100
> Pavel Stehule wrote:
>
>
>> a) simplicity. PLpgSQL interpret is very simple.
>> b) mostly types are little bit different behave than natural C
>> types - domains are different, C types doesn't know NULL value, ...
>
> But we
Pavel Stehule wrote:
> The problem is massive cycle. Plpgsql really isn't language for this.
> This interpret missing own arithmetic unit. So every expression is
> translated to SELECT statement
>
> IF a > c ~ SELECT a > c
> a = a + 1 ~ SELECT a + 1
>
> these queries are executed in some special
On Wed, 23 Dec 2009 14:35:27 +0100
Pavel Stehule wrote:
> a) simplicity. PLpgSQL interpret is very simple.
> b) mostly types are little bit different behave than natural C
> types - domains are different, C types doesn't know NULL value, ...
But well... there should be a mapping somewhere betwe
2009/12/23 Ivan Sergio Borgonovo :
> On Wed, 23 Dec 2009 12:52:38 +0100
> Pavel Stehule wrote:
>
>> The problem is massive cycle. Plpgsql really isn't language for
>> this. This interpret missing own arithmetic unit. So every
>> expression is translated to SELECT statement
>>
>> IF a > c ~ SELECT
On Wed, 23 Dec 2009 12:52:38 +0100
Pavel Stehule wrote:
> The problem is massive cycle. Plpgsql really isn't language for
> this. This interpret missing own arithmetic unit. So every
> expression is translated to SELECT statement
>
> IF a > c ~ SELECT a > c
> a = a + 1 ~ SELECT a + 1
> these qu
2009/12/23 Ivan Sergio Borgonovo :
> On Wed, 23 Dec 2009 08:38:52 +0100
> Pavel Stehule wrote:
>
>> > As even more unexpected... when all row are >0 and most of them
>> > are equal to 1 the generate_series performs appreciably better
>> > (roughly 15% faster).
>> > And I think your version can be
On Wed, 23 Dec 2009 08:38:52 +0100
Pavel Stehule wrote:
> > As even more unexpected... when all row are >0 and most of them
> > are equal to 1 the generate_series performs appreciably better
> > (roughly 15% faster).
> > And I think your version can be further optimised:
> > select count(*) from
In response to Bryce Nesbitt :
> Dear experts,
>
> This point is confusing me with the || operator. I've got a table with
> "one column per data type", like so:
>
> # \d context_keyvals;
> Table "public.context_keyvals"
>Column|Type | Modifiers
> --
On 23/12/2009 4:34 PM, Bryce Nesbitt wrote:
Dear experts,
This point is confusing me with the || operator. I've got a table with
"one column per data type", like so:
Dare I ask why? What problem are you trying to solve by doing this?
# select context_key,keyname,t_number||t_string||t_date||t
Dear experts,
This point is confusing me with the || operator. I've got a table with
"one column per data type", like so:
# \d context_keyvals;
Table "public.context_keyvals"
Column|Type | Modifiers
-+-+---
14 matches
Mail list logo
