On Sun, Sep 13, 2009 at 10:32 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 11, 2009 at 12:09 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2009/8/10 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jul 26, 2009 at 9:29 AM, Pavel
On Tue, Aug 11, 2009 at 12:09 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2009/8/10 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehulepavel.steh...@gmail.com
wrote:
new patch add new contrib transformations with three
On Mon, Aug 10, 2009 at 03:43:45PM -0400, Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Still, it rates pretty high on my astonishment scale that a
COALESCE of two untyped NULLs (or
On Tue, Aug 11, 2009 at 6:35 AM, Sam Masons...@samason.me.uk wrote:
On Mon, Aug 10, 2009 at 03:43:45PM -0400, Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Still, it rates pretty high
2009/8/9 Alvaro Herrera alvhe...@commandprompt.com:
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
2009/8/9 Jeff Davis pg...@j-davis.com:
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
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 proposed
2009/8/10 Peter Eisentraut pete...@gmx.net:
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
Peter Eisentraut pete...@gmx.net 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Peter Eisentraut pete...@gmx.net 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=#
On Mon, Aug 10, 2009 at 5:54 PM, Kevin
Grittnerkevin.gritt...@wicourts.gov 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
Greg Stark gsst...@mit.edu 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.
Kevin Grittner kevin.gritt...@wicourts.gov 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
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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,
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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
Tom Lane t...@sss.pgh.pa.us 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
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
Robert Haas robertmh...@gmail.com writes:
On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehulepavel.steh...@gmail.com 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.
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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)
Kevin Grittner kevin.gritt...@wicourts.gov 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
Resending to correct a copy/paste error. Apologies.
Kevin Grittner kevin.gritt...@wicourts.gov 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
2009/8/10 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehulepavel.steh...@gmail.com
wrote:
new patch add new contrib transformations with three modules
anotation, decode and json.
These are pretty good examples, but the
2009/8/10 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehulepavel.steh...@gmail.com
wrote:
new patch add new contrib transformations with three modules
anotation, decode and json.
These are pretty good examples, but the
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
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 Sat, Aug 8, 2009 at 9:11 PM, Jeff Davispg...@j-davis.com 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
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 need it,
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
referring to?
Hi,
Robert Haas robertmh...@gmail.com 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
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 fields
On Thu, Jul 30, 2009 at 1:22 AM, Pavel Stehulepavel.steh...@gmail.com wrote:
2009/7/30 Robert Haas robertmh...@gmail.com:
On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehulepavel.steh...@gmail.com
wrote:
Hello
new patch add new contrib transformations with three modules
anotation, decode and
2009/8/4 Robert Haas robertmh...@gmail.com:
On Thu, Jul 30, 2009 at 1:22 AM, Pavel Stehulepavel.steh...@gmail.com wrote:
2009/7/30 Robert Haas robertmh...@gmail.com:
On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehulepavel.steh...@gmail.com
wrote:
Hello
new patch add new contrib transformations
On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehulepavel.steh...@gmail.com 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
Hello
2009/7/30 Robert Haas robertmh...@gmail.com:
On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehulepavel.steh...@gmail.com 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
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 Stehule
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 pavel.steh...@gmail.com:
Hello
new patch add new contrib transformations with three modules
anotation, decode and json.
These modules are
On Mon, Apr 20, 2009 at 8:45 AM, Pavel Stehulepavel.steh...@gmail.com wrote:
2009/4/18 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/4/11 Tom Lane t...@sss.pgh.pa.us:
No, I was complaining that a hook right there is useless and expensive.
transformExpr() is
Robert Haas robertmh...@gmail.com 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
Hello
2009/7/25 Robert Haas robertmh...@gmail.com:
On Mon, Apr 20, 2009 at 8:45 AM, Pavel Stehulepavel.steh...@gmail.com wrote:
2009/4/18 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/4/11 Tom Lane t...@sss.pgh.pa.us:
No, I was complaining that a hook right
On Sat, Jul 25, 2009 at 11:38 PM, Pavel Stehulepavel.steh...@gmail.com wrote:
Hello
2009/7/25 Robert Haas robertmh...@gmail.com:
On Mon, Apr 20, 2009 at 8:45 AM, Pavel Stehulepavel.steh...@gmail.com
wrote:
2009/4/18 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
On Sunday 19 April 2009 20:47:37 Pavel Stehule wrote:
2009/4/19 Peter Eisentraut pete...@gmx.net:
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
2009/4/20 Peter Eisentraut pete...@gmx.net:
On Sunday 19 April 2009 20:47:37 Pavel Stehule wrote:
2009/4/19 Peter Eisentraut pete...@gmx.net:
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
2009/4/18 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/4/11 Tom Lane t...@sss.pgh.pa.us:
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
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
Peter Eisentraut pete...@gmx.net 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
2009/4/20 Peter Eisentraut pete...@gmx.net:
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
2009/4/20 Tom Lane t...@sss.pgh.pa.us:
Peter Eisentraut pete...@gmx.net 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
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 should
2009/4/19 Peter Eisentraut pete...@gmx.net:
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,
Hello
2009/4/11 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/4/11 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
I am sending small patch, that allows hooking transformation stage of
parser.
Isn't this the exact same patch we
Pavel Stehule pavel.steh...@gmail.com writes:
2009/4/11 Tom Lane t...@sss.pgh.pa.us:
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
2009/4/18 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/4/11 Tom Lane t...@sss.pgh.pa.us:
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
Pavel Stehule pavel.steh...@gmail.com 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
2009/4/11 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
Pavel Stehule pavel.steh...@gmail.com writes:
2009/4/11 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
2009/4/11 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/4/11 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
I am sending small patch, that allows hooking transformation stage of
parser.
Isn't this the exact same patch we
57 matches
Mail list logo
