On Sun, Sep 13, 2009 at 10:32 PM, Robert Haas wrote:
> On Tue, Aug 11, 2009 at 12:09 AM, Pavel Stehule
> wrote:
>> 2009/8/10 Tom Lane :
>>> Robert Haas writes:
On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule
wrote:
> new patch add new contrib "transformations" with three modules
>
On Tue, Aug 11, 2009 at 12:09 AM, Pavel Stehule wrote:
> 2009/8/10 Tom Lane :
>> Robert Haas writes:
>>> On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule
>>> wrote:
new patch add new contrib "transformations" with three modules
anotation, decode and json.
>>
>>> These are pretty good exa
On Tue, Aug 11, 2009 at 6:35 AM, Sam Mason wrote:
> On Mon, Aug 10, 2009 at 03:43:45PM -0400, Tom Lane wrote:
>> "Kevin Grittner" writes:
>> > Tom Lane wrote:
>> >> "Kevin Grittner" writes:
>> >>> Still, it rates pretty high on my astonishment scale that a
>> >>> COALESCE of two untyped NULLs (o
On Mon, Aug 10, 2009 at 03:43:45PM -0400, Tom Lane wrote:
> "Kevin Grittner" writes:
> > Tom Lane wrote:
> >> "Kevin Grittner" writes:
> >>> Still, it rates pretty high on my astonishment scale that a
> >>> COALESCE of two untyped NULLs (or for that matter, any two values
> >>> of unknown type)
2009/8/10 Tom Lane :
> Robert Haas writes:
>> On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule
>> wrote:
>>> new patch add new contrib "transformations" with three modules
>>> anotation, decode and json.
>
>> These are pretty good examples, but the whole thing still feels a bit
>> grotty to me. Th
2009/8/10 Tom Lane :
> Robert Haas writes:
>> On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule
>> wrote:
>>> new patch add new contrib "transformations" with three modules
>>> anotation, decode and json.
>
>> These are pretty good examples, but the whole thing still feels a bit
>> grotty to me. Th
Resending to correct a copy/paste error. Apologies.
"Kevin Grittner" wrote:
> Yeah -- my argument would be that the = operator in NULLIF should be
> treated the same as if the function-like abbreviation were rewritten
> to the full CASE predicate. It doesn't surprise me that that is
> taken
"Kevin Grittner" wrote:
> Yeah -- my argument would be that the = operator in NULLIF should be
> treated the same as if the function-like abbreviation were rewritten
> to the full CASE predicate. It doesn't surprise me that that is
> taken as text, given that they are both unadorned character
Tom Lane wrote:
> "Kevin Grittner" writes:
[Correcting typo below.]
>> Well, in the SQL specification, COALESCE is defined as an
>> abbreviation of the CASE predicate, so to the extent that anyone
>> pays attention to the spec, this:
>> COALESCE(a, b)
>> should be treated identically to:
>>
"Kevin Grittner" writes:
> Tom Lane wrote:
>> In the specific case of COALESCE, we could theoretically do that,
>> since the only computation it needs is "IS NULL" which is
>> datatype-independent.
> Well, in the SQL specification, COALESCE is defined as an abbreviation
> of the CASE predicate,
Robert Haas writes:
> On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule wrote:
>> new patch add new contrib "transformations" with three modules
>> anotation, decode and json.
> These are pretty good examples, but the whole thing still feels a bit
> grotty to me. The set of syntax transformations t
I wrote:
> COALESCE(a, b)
>
> should be treated identically to:
>
> CASE WHEN a IS NULL THEN a ELSE b END
In case it's not obvious that the above has a typo, I meant:
CASE WHEN a IS NOT NULL THEN a ELSE b END
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
Tom Lane wrote:
> In the specific case of COALESCE, we could theoretically do that,
> since the only computation it needs is "IS NULL" which is
> datatype-independent.
Well, in the SQL specification, COALESCE is defined as an abbreviation
of the CASE predicate, so to the extent that anyone pay
"Kevin Grittner" writes:
> Tom Lane wrote:
>> "Kevin Grittner" writes:
>>> Still, it rates pretty high on my astonishment scale that a
>>> COALESCE of two untyped NULLs (or for that matter, any two values
>>> of unknown type) returns a text value.
>>
>> What would you have it do instead, throw
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Still, it rates pretty high on my astonishment scale that a
>> COALESCE of two untyped NULLs (or for that matter, any two values
>> of unknown type) returns a text value.
>
> What would you have it do instead, throw an error?
Return a value of unk
"Kevin Grittner" writes:
> Still, it rates pretty high on my astonishment scale that a
> COALESCE of two untyped NULLs (or for that matter, any two values of
> unknown type) returns a text value.
What would you have it do instead, throw an error?
The current behavior is a lot less astonishing fo
Greg Stark wrote:
> Given that pg_typeof() is a relatively new and pg-specific piece of
> machinery how did this bite you on on your conversion to Postgres
> some years ago?
It wasn't the use of pg_typeof which caused us problems, but the types
the example demonstrated. Primarily that bit us
On Mon, Aug 10, 2009 at 5:54 PM, Kevin
Grittner wrote:
>
> We now have workarounds in place for everywhere this bit us on
> conversion to PostgreSQL, but it was actually one of the greater
> sources of pain in that process
Given that pg_typeof() is a relatively new and pg-specific piece of
mac
"Kevin Grittner" writes:
> Peter Eisentraut wrote:
>> reimplement a bunch of core functionality like COALESCE
> If such an effort could reduce the astonishment factor for the
> following, it would justify a certain amount of effort, in my view:
> test=# select pg_typeof('x');
> pg_typeof
>
Peter Eisentraut wrote:
> reimplement a bunch of core functionality like COALESCE
If such an effort could reduce the astonishment factor for the
following, it would justify a certain amount of effort, in my view:
test=# select pg_typeof('x');
pg_typeof
---
unknown
(1 row)
test=#
2009/8/10 Peter Eisentraut :
> On Sunday 09 August 2009 05:21:48 Jeff Davis wrote:
>> * If the hook can implement XML, should we refactor the XML support (and
>> COALESCE, etc.) to use the hook for the sake of consistency? If the hook
>> is not good enough for those features, that might indicate a
On Sunday 09 August 2009 05:21:48 Jeff Davis wrote:
> * If the hook can implement XML, should we refactor the XML support (and
> COALESCE, etc.) to use the hook for the sake of consistency? If the hook
> is not good enough for those features, that might indicate a problem.
Well, for 8.4, I propose
2009/8/9 Jeff Davis :
> On Sun, 2009-07-26 at 15:29 +0200, Pavel Stehule wrote:
>> Hello
>>
>> new patch add new contrib "transformations" with three modules
>> anotation, decode and json.
>>
>> These modules are ported from my older work.
>>
>> Before applying this patch, please use named-fixed pa
2009/8/9 Alvaro Herrera :
> Jeff Davis escribió:
>> On Mon, 2009-04-20 at 18:53 +0200, Pavel Stehule wrote:
>> > b) it allows constructors for data types (ANSI SQL)
>> >
>> > datatype(typefield1[, typefiedl2[, typefiedl3[, ...]]]) returns type
>>
>> Can you describe this case in more detail? What s
Jeff Davis escribió:
> On Mon, 2009-04-20 at 18:53 +0200, Pavel Stehule wrote:
> > b) it allows constructors for data types (ANSI SQL)
> >
> > datatype(typefield1[, typefiedl2[, typefiedl3[, ...]]]) returns type
>
> Can you describe this case in more detail? What section of SQL are you
> referrin
On Sun, 2009-07-26 at 15:29 +0200, Pavel Stehule wrote:
> Hello
>
> new patch add new contrib "transformations" with three modules
> anotation, decode and json.
>
> These modules are ported from my older work.
>
> Before applying this patch, please use named-fixed patch too. The hook
> doesn't n
On Sat, Aug 8, 2009 at 9:11 PM, Jeff Davis wrote:
> On Thu, 2009-07-30 at 00:01 -0400, Robert Haas wrote:
>> The JSON transformation provides functionality which is very similar
>> to what we also offer for XML. I sort of think we ought to just
>> provide that, rather than making it an add-on. I
On Mon, 2009-04-20 at 18:53 +0200, Pavel Stehule wrote:
> b) it allows constructors for data types (ANSI SQL)
>
> datatype(typefield1[, typefiedl2[, typefiedl3[, ...]]]) returns type
Can you describe this case in more detail? What section of SQL are you
referring to?
Regards,
Jeff Davis
On Thu, 2009-07-30 at 00:01 -0400, Robert Haas wrote:
> The JSON transformation provides functionality which is very similar
> to what we also offer for XML. I sort of think we ought to just
> provide that, rather than making it an add-on. I have found it to be
> a tremendously attractive alterna
Hello
>
> * UBF(B) is a programming langauge for describing types in UBF(A)
> and protocols between clients and servers. UBF(B) is roughly
> equivalent to to Verified XML, XML-schemas, SOAP and WDSL.
>
SOAP is nice sample for Parser Hook -
is soap call there are some immutable field
Hi,
Robert Haas writes:
> I don't really believe that JSON is "only one use case". XML and JSON
> are in a class of their own; there's nothing else out there that is
> really comparable.
You might want to hear about the UBF specs from Joe Armstrong, let me
quote its page about it:
UBF is a l
2009/8/4 Robert Haas :
> On Thu, Jul 30, 2009 at 1:22 AM, Pavel Stehule wrote:
>> 2009/7/30 Robert Haas :
>>> On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule
>>> wrote:
Hello
new patch add new contrib "transformations" with three modules
anotation, decode and json.
The
On Thu, Jul 30, 2009 at 1:22 AM, Pavel Stehule wrote:
> 2009/7/30 Robert Haas :
>> On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule
>> wrote:
>>> Hello
>>>
>>> new patch add new contrib "transformations" with three modules
>>> anotation, decode and json.
>>>
>>> These modules are ported from my olde
Hello
2009/7/30 Robert Haas :
> On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule wrote:
>> Hello
>>
>> new patch add new contrib "transformations" with three modules
>> anotation, decode and json.
>>
>> These modules are ported from my older work.
>>
>> Before applying this patch, please use named-f
On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule wrote:
> Hello
>
> new patch add new contrib "transformations" with three modules
> anotation, decode and json.
>
> These modules are ported from my older work.
>
> Before applying this patch, please use named-fixed patch too. The hook
> doesn't need i
Hello
note about SQL:201x
http://blogs.mysql.com/peterg/2009/06/07/soothsaying-sql-standardization-stuff/
regards
Pavel Stehule
2009/7/26 Pavel Stehule :
> Hello
>
> new patch add new contrib "transformations" with three modules
> anotation, decode and json.
>
> These modules are ported from my
Hello
new patch add new contrib "transformations" with three modules
anotation, decode and json.
These modules are ported from my older work.
Before applying this patch, please use named-fixed patch too. The hook
doesn't need it, but modules anotation and json depend on it.
Regards
Pavel Stehul
On Sat, Jul 25, 2009 at 11:38 PM, Pavel Stehule wrote:
> Hello
>
> 2009/7/25 Robert Haas :
>> On Mon, Apr 20, 2009 at 8:45 AM, Pavel Stehule
>> wrote:
>>> 2009/4/18 Tom Lane :
Pavel Stehule writes:
> 2009/4/11 Tom Lane :
>> No, I was complaining that a hook right there is useless and
Hello
2009/7/25 Robert Haas :
> On Mon, Apr 20, 2009 at 8:45 AM, Pavel Stehule wrote:
>> 2009/4/18 Tom Lane :
>>> Pavel Stehule writes:
2009/4/11 Tom Lane :
> No, I was complaining that a hook right there is useless and expensive.
> transformExpr() is executed multiple times per quer
Robert Haas writes:
> I think we should apply the same criteria to this that we
> have to some other patches that have been rejected (like the
> extensible-rmgr patch Simon submitted for CommitFest 2008-11), namely,
> requiring that the extension mechanism be submitted together with at
> least two
On Mon, Apr 20, 2009 at 8:45 AM, Pavel Stehule wrote:
> 2009/4/18 Tom Lane :
>> Pavel Stehule writes:
>>> 2009/4/11 Tom Lane :
No, I was complaining that a hook right there is useless and expensive.
transformExpr() is executed multiple times per query, potentially a very
large numbe
2009/4/20 Tom Lane :
> Peter Eisentraut writes:
>> I find this all a bit premature, given that you haven't clearly defined what
>> sort of user-visible functionality you hope to end up implementing.
>
> That sums up my reaction too --- this looks like a solution in search of
> a problem. The hook
2009/4/20 Peter Eisentraut :
> On Monday 20 April 2009 09:52:05 Pavel Stehule wrote:
>> I don't believe so is possible to find other general solution. (or
>> better I didn't find any other solution). Tom has true,
>> transformationHook on expression is expensive. I thing, so hook on
>> function sho
Peter Eisentraut writes:
> I find this all a bit premature, given that you haven't clearly defined what
> sort of user-visible functionality you hope to end up implementing.
That sums up my reaction too --- this looks like a solution in search of
a problem. The hook itself might be relatively h
On Monday 20 April 2009 09:52:05 Pavel Stehule wrote:
> I don't believe so is possible to find other general solution. (or
> better I didn't find any other solution). Tom has true,
> transformationHook on expression is expensive. I thing, so hook on
> function should be simple and fast - not all tr
2009/4/18 Tom Lane :
> Pavel Stehule writes:
>> 2009/4/11 Tom Lane :
>>> No, I was complaining that a hook right there is useless and expensive.
>>> transformExpr() is executed multiple times per query, potentially a very
>>> large number of times per query; so even testing to see if a hook exists
2009/4/20 Peter Eisentraut :
> On Sunday 19 April 2009 20:47:37 Pavel Stehule wrote:
>> 2009/4/19 Peter Eisentraut :
>> > On Saturday 18 April 2009 18:09:00 Pavel Stehule wrote:
>> >> There are lot of things, that should be done with current grammar only
>> >> on transformation stage. Currently pg
On Sunday 19 April 2009 20:47:37 Pavel Stehule wrote:
> 2009/4/19 Peter Eisentraut :
> > On Saturday 18 April 2009 18:09:00 Pavel Stehule wrote:
> >> There are lot of things, that should be done with current grammar only
> >> on transformation stage. Currently pg do it now. There are lot of
> >> ps
2009/4/19 Peter Eisentraut :
> On Saturday 18 April 2009 18:09:00 Pavel Stehule wrote:
>> There are lot of things, that should be done with current grammar only
>> on transformation stage. Currently pg do it now. There are lot of
>> pseudo functions, that are specially transformed: least, greatest,
On Saturday 18 April 2009 18:09:00 Pavel Stehule wrote:
> There are lot of things, that should be done with current grammar only
> on transformation stage. Currently pg do it now. There are lot of
> pseudo functions, that are specially transformed: least, greatest,
> coalesce. After hooking we shou
2009/4/18 Tom Lane :
> Pavel Stehule writes:
>> 2009/4/11 Tom Lane :
>>> No, I was complaining that a hook right there is useless and expensive.
>>> transformExpr() is executed multiple times per query, potentially a very
>>> large number of times per query; so even testing to see if a hook exists
Pavel Stehule writes:
> 2009/4/11 Tom Lane :
>> No, I was complaining that a hook right there is useless and expensive.
>> transformExpr() is executed multiple times per query, potentially a very
>> large number of times per query; so even testing to see if a hook exists
>> is not a negligible cos
Hello
2009/4/11 Tom Lane :
> Pavel Stehule writes:
>> 2009/4/11 Tom Lane :
>>> Pavel Stehule writes:
I am sending small patch, that allows hooking transformation stage of
parser.
>>>
>>> Isn't this the exact same patch we rejected several months ago?
>
>> What I remember, You had some
2009/4/11 Tom Lane :
> Pavel Stehule writes:
>> 2009/4/11 Tom Lane :
>>> Pavel Stehule writes:
I am sending small patch, that allows hooking transformation stage of
parser.
>>>
>>> Isn't this the exact same patch we rejected several months ago?
>
>> What I remember, You had some object
Pavel Stehule writes:
> 2009/4/11 Tom Lane :
>> Pavel Stehule writes:
>>> I am sending small patch, that allows hooking transformation stage of
>>> parser.
>>
>> Isn't this the exact same patch we rejected several months ago?
> What I remember, You had some objections about different behave be
2009/4/11 Tom Lane :
> Pavel Stehule writes:
>> I am sending small patch, that allows hooking transformation stage of parser.
>
> Isn't this the exact same patch we rejected several months ago?
>
> regards, tom lane
What I remember, You had some objections about different
Pavel Stehule writes:
> I am sending small patch, that allows hooking transformation stage of parser.
Isn't this the exact same patch we rejected several months ago?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
57 matches
Mail list logo
