Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I think we have a few TODO items here:
> >>
> >> * Invent ... and document ... an API that permits safe assembly of a
> >> parameter list from non-constant (and perhaps untrustworthy) values.
> >>
> >> * Fix xslt_process' failure t
Bruce Momjian writes:
> Tom Lane wrote:
>> I think we have a few TODO items here:
>>
>> * Invent ... and document ... an API that permits safe assembly of a
>> parameter list from non-constant (and perhaps untrustworthy) values.
>>
>> * Fix xslt_process' failure to report (some?) errors detected
Tom Lane wrote:
> Mike Fowler writes:
> > On 06/08/10 17:50, Pavel Stehule wrote:
> >> attached updated patch with regression test
>
> > Bravely ignoring the quotation/varidic/
> > conversations, I've taken a look at the patch as is. Thanks to Tom's
> > input I can now correctly drive the funct
Mike Fowler writes:
> On 06/08/10 17:50, Pavel Stehule wrote:
>> attached updated patch with regression test
> Bravely ignoring the quotation/varidic/
> conversations, I've taken a look at the patch as is. Thanks to Tom's
> input I can now correctly drive the function. I can also report that
>
Robert Haas writes:
> Right. So, what about Mike's idea of extracting this into a new
> contrib module, perhaps contrib/xslt? That might also provide a good
> excuse to jettison any details of the existing interfaces that we
> happen to find unfortunate.
Seems like mostly make-work to me --- we
On Mon, Aug 9, 2010 at 10:14 AM, Tom Lane wrote:
> Mike Fowler writes:
>> Turns out the bug was filed in 2005 (see
>> https://bugzilla.gnome.org/show_bug.cgi?id=307061). They are currently
>> taking a fairly loose interpretation of the XSLT spec. However that was
>> only one aspect of the concern
Mike Fowler writes:
> Turns out the bug was filed in 2005 (see
> https://bugzilla.gnome.org/show_bug.cgi?id=307061). They are currently
> taking a fairly loose interpretation of the XSLT spec. However that was
> only one aspect of the concern. The other was that no errors were being
> reported
On 09/08/10 04:07, Tom Lane wrote:
Robert Haas writes:
On Sun, Aug 8, 2010 at 11:36 AM, Mike Fowler wrote:
1) XML2 is largely undocumented, giving rise to the problems encountered.
Since the module is deprecated anyways, does it make more sense to get xslt
handling moved into core and get it
Robert Haas writes:
> On Sun, Aug 8, 2010 at 11:36 AM, Mike Fowler wrote:
>> 1) XML2 is largely undocumented, giving rise to the problems encountered.
>> Since the module is deprecated anyways, does it make more sense to get xslt
>> handling moved into core and get it fully documented?
> Yes, I
On Sun, Aug 8, 2010 at 11:36 AM, Mike Fowler wrote:
> On 06/08/10 17:50, Pavel Stehule wrote:
>> attached updated patch with regression test
>
> Bravely ignoring the quotation/varidic/
> conversations,
Thank you!
> I've taken a look at the patch as is.
Excellent.
> Thanks to Tom's input I
> ca
2010/8/8 David E. Wheeler :
> On Aug 8, 2010, at 9:10 AM, Pavel Stehule wrote:
>
>>> There are no keys.
>>
>> ok - I didn't use a correct name - so "indexed set" is better.
>
> Hash?
Just only hash isn't good model, because I sometimes we would prefer a
ordered set
Regards
Pavel
>
> David
>
>
2010/8/8 Kevin Grittner :
> Pavel Stehule wrote:
>
>> I didn't use a correct name - so "indexed set" is better.
>
> How would such a thing differ from a RAM-based local temporary table?
temporary tables are too heavy for this purposes. In SQL environment I
expecting a transactional behave from ta
On Aug 8, 2010, at 9:10 AM, Pavel Stehule wrote:
>> There are no keys.
>
> ok - I didn't use a correct name - so "indexed set" is better.
Hash?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
Pavel Stehule wrote:
> I didn't use a correct name - so "indexed set" is better.
How would such a thing differ from a RAM-based local temporary table?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
2010/8/8 David E. Wheeler :
> On Aug 7, 2010, at 11:05 PM, Pavel Stehule wrote:
>
>>> COLLECTION?
>>
>> yes, sorry - simply - class where fields can be accessed via specified
>> index - unique or not unique.
>
> Like in Oracle? From:
> http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14261
On Aug 7, 2010, at 11:05 PM, Pavel Stehule wrote:
>> COLLECTION?
>
> yes, sorry - simply - class where fields can be accessed via specified
> index - unique or not unique.
Like in Oracle? From:
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14261/collections.htm
> A collection is an
On 06/08/10 17:50, Pavel Stehule wrote:
attached updated patch with regression test
Bravely ignoring the quotation/varidic/
conversations, I've taken a look at the patch as is. Thanks to Tom's
input I can now correctly drive the function. I can also report that
code is now behaving in
2010/8/8 David E. Wheeler :
> On Aug 7, 2010, at 12:24 AM, Pavel Stehule wrote:
>
>>> try=# create or replace function try(bool) returns text language plperl AS
>>> 'shift';
>>> CREATE FUNCTION
>>> Time: 121.403 ms
>>> try=# select try(true);
>>> try
>>> -
>>> t
>>> (1 row)
>>>
>>> I wish th
On Aug 7, 2010, at 12:24 AM, Pavel Stehule wrote:
>> try=# create or replace function try(bool) returns text language plperl AS
>> 'shift';
>> CREATE FUNCTION
>> Time: 121.403 ms
>> try=# select try(true);
>> try
>> -
>> t
>> (1 row)
>>
>> I wish this wasn't so.
>>
>
> It must not be - i
2010/8/7 David E. Wheeler :
> On Aug 6, 2010, at 10:49 PM, Pavel Stehule wrote:
>
>>> Huh? You can select into an array:
>>
>> and pg doesn't handle 2D arrays well - can't to use ARRAY(subselect)
>> constructor for 2D arrays
>
> Right.
>
>>> try=# select ARRAY(SELECT ARRAY[k,v] FROM foo);
>>> ERROR
On Aug 6, 2010, at 10:49 PM, Pavel Stehule wrote:
>> Huh? You can select into an array:
>
> and pg doesn't handle 2D arrays well - can't to use ARRAY(subselect)
> constructor for 2D arrays
Right.
>> try=# select ARRAY(SELECT ARRAY[k,v] FROM foo);
>> ERROR: could not find array type for datatyp
2010/8/7 David E. Wheeler :
> On Aug 6, 2010, at 10:15 PM, Pavel Stehule wrote:
>
>>> This is not exactly without precedent, either: our built-in xpath()
>>> function appears to use precisely this approach for its namespace-list
>>> argument.
>>
>> it's one variant, but isn't perfect
>>
>> a) it ex
2010/8/7 David E. Wheeler :
> On Aug 6, 2010, at 9:48 PM, Pavel Stehule wrote:
>
>>> That's exactly what my solution does. The array solution doesn't. Whether
>>> it's appropriate to use a custom composite type, however, is an open
>>> question.
>>
>> no it doesn't - in your design there are no d
On Aug 6, 2010, at 10:15 PM, Pavel Stehule wrote:
>> This is not exactly without precedent, either: our built-in xpath()
>> function appears to use precisely this approach for its namespace-list
>> argument.
>
> it's one variant, but isn't perfect
>
> a) it expects so key and value are literals
On Aug 6, 2010, at 9:59 PM, Tom Lane wrote:
> It's not immediately clear to me what an ordered-pair type would get you
> that you don't get with 2-element arrays.
Just syntactic sugar, really. And control over how many items you have (a
bounded pair rather than an unlimited element array).
> A
2010/8/7 Tom Lane :
> "David E. Wheeler" writes:
>> I think that some sort of variadic pairs would be useful for this. But since
>> there is no core "ordered pair" data type, I don't think you're going to get
>> too far.
>
> It's not immediately clear to me what an ordered-pair type would get yo
On Aug 6, 2010, at 9:48 PM, Pavel Stehule wrote:
>> That's exactly what my solution does. The array solution doesn't. Whether
>> it's appropriate to use a custom composite type, however, is an open
>> question.
>
> no it doesn't - in your design there are no different notation for key
> and for
"David E. Wheeler" writes:
> I think that some sort of variadic pairs would be useful for this. But since
> there is no core "ordered pair" data type, I don't think you're going to get
> too far.
It's not immediately clear to me what an ordered-pair type would get you
that you don't get with 2-
2010/8/7 David E. Wheeler :
> On Aug 6, 2010, at 8:49 PM, Pavel Stehule wrote:
>
>>> Sorry, not following you here
>>
>> I would to difference a key and value in notation.
>
> That's exactly what my solution does. The array solution doesn't. Whether
> it's appropriate to use a custom composite typ
On Aug 6, 2010, at 8:49 PM, Pavel Stehule wrote:
>> Sorry, not following you here
>
> I would to difference a key and value in notation.
That's exactly what my solution does. The array solution doesn't. Whether it's
appropriate to use a custom composite type, however, is an open question.
>> P
2010/8/7 Tom Lane :
> "David E. Wheeler" writes:
>> On Aug 6, 2010, at 2:12 PM, Pavel Stehule wrote:
>>> so there is only small step to proposed feature
>>> SELECT foo(this := 'that', "1" := 4)
>
>> Sorry, not following you here
I would to difference a key and value in notation.
>
> Pavel doesn'
On Fri, Aug 06, 2010 at 11:48:58PM +0300, Peter Eisentraut wrote:
> On fre, 2010-08-06 at 21:31 +0200, Pavel Stehule wrote:
> > It must not be a function. Just I missing any tool that helps with
> > complex structured data. This proposed kind functions has one
> > advantage - there isn't necessary
"David E. Wheeler" writes:
> On Aug 6, 2010, at 2:12 PM, Pavel Stehule wrote:
>> so there is only small step to proposed feature
>> SELECT foo(this := 'that', "1" := 4)
> Sorry, not following you here
Pavel doesn't understand "no" ;-)
regards, tom lane
--
Sent via pgsq
Peter Eisentraut writes:
> On fre, 2010-08-06 at 13:01 -0400, Tom Lane wrote:
>> 2. I'm not sure whether we ought to auto-single-quote the values.
>> If we don't, how hard is it for users to properly quote nonconstant
>> parameter values? (Will quote_literal work, or are the quoting rules
>> diff
On Aug 6, 2010, at 2:12 PM, Pavel Stehule wrote:
>> SELECT foo('this' ~> 'that', 1 ~> 4);
>>
>> Not bad, I think. I kind of like it. It reminds me how much I hate the %
>> hstore construction operator, though (the new name for =>).
>
> so there is only small step to proposed feature
>
> SELECT
2010/8/6 David E. Wheeler :
> On Aug 6, 2010, at 1:49 PM, Pavel Stehule wrote:
>
>> yes it is one a possibility and probably best. The nice of this
>> variant can be two forms like current variadic does - foo(.., a :=
>> 10, b := 10) or foo(.., variadic ARRAY[(a,10),(b,10)])
>
> I started fiddling
On Fri, Aug 6, 2010 at 1:46 PM, Pavel Stehule wrote:
> I'll propose a new kind of functions (only position parameter's
> function). My idea is simple - for functions with this mark the mixed
> and named notation is blocked. But these functions can have a
> parameter names - and these names can be
On Aug 6, 2010, at 1:49 PM, Pavel Stehule wrote:
> yes it is one a possibility and probably best. The nice of this
> variant can be two forms like current variadic does - foo(.., a :=
> 10, b := 10) or foo(.., variadic ARRAY[(a,10),(b,10)])
I started fiddling and got as far as this:
CREATE TYP
> yes it is one a possibility and probably best. The nice of this
> variant can be two forms like current variadic does - foo(.., a :=
> 10, b := 10) or foo(.., variadic ARRAY[(a,10),(b,10)])
>
>
pardon foo(..., VARIADIC ARRAY[('a', 10), ('b' 10)])
regards
Pavel
--
Sent via pgsql-hackers maili
2010/8/6 Peter Eisentraut :
> On fre, 2010-08-06 at 21:31 +0200, Pavel Stehule wrote:
>> It must not be a function. Just I missing any tool that helps with
>> complex structured data. This proposed kind functions has one
>> advantage - there isn't necessary any change in parser. Yes, I can use
>> a
2010/8/6 David E. Wheeler :
> On Aug 6, 2010, at 11:13 AM, Tom Lane wrote:
>
>> That would work too, although I think it might be a bit harder to use
>> than one alternating-name-and-value array, at least in some scenarios.
>> You'd have to be careful that you got the values in the same order in
>>
On fre, 2010-08-06 at 21:31 +0200, Pavel Stehule wrote:
> It must not be a function. Just I missing any tool that helps with
> complex structured data. This proposed kind functions has one
> advantage - there isn't necessary any change in parser. Yes, I can use
> a pair of arrays, I can use a one a
On fre, 2010-08-06 at 13:01 -0400, Tom Lane wrote:
> 2. I'm not sure whether we ought to auto-single-quote the values.
> If we don't, how hard is it for users to properly quote nonconstant
> parameter values? (Will quote_literal work, or are the quoting rules
> different for libxslt?) If we do, a
On Aug 6, 2010, at 11:13 AM, Tom Lane wrote:
> That would work too, although I think it might be a bit harder to use
> than one alternating-name-and-value array, at least in some scenarios.
> You'd have to be careful that you got the values in the same order in
> both arrays, which'd be easy to bo
2010/8/6 Tom Lane :
> Pavel Stehule writes:
>> For Tom: proposed syntax can be used generally - everywhere when you
>> are working with collection. It can be used for hash (hstore)
>> constructor for example. For me is more readable code like
>
>> select hstore(name := 'Tomas', surname := 'Novak')
Pavel Stehule writes:
> For Tom: proposed syntax can be used generally - everywhere when you
> are working with collection. It can be used for hash (hstore)
> constructor for example. For me is more readable code like
> select hstore(name := 'Tomas', surname := 'Novak')
You've tried to sell us o
Robert Haas writes:
> Why wouldn't we just pass two text arrays to this function and be done
> with it?
That would work too, although I think it might be a bit harder to use
than one alternating-name-and-value array, at least in some scenarios.
You'd have to be careful that you got the values in
2010/8/6 Robert Haas :
> On Fri, Aug 6, 2010 at 1:46 PM, Pavel Stehule wrote:
>> I'll propose a new kind of functions (only position parameter's
>> function). My idea is simple - for functions with this mark the mixed
>> and named notation is blocked. But these functions can have a
>> parameter na
Pavel Stehule writes:
> 2010/8/6 Tom Lane :
>> I think there are issues here that we need to take a step back and think
>> about. Â Right now, thanks to the lack of documentation, we can probably
>> assume there are approximately zero users of the xslt_process parameter
>> feature. Â Once we docum
2010/8/6 Tom Lane :
> Andrew Dunstan writes:
>> On 08/06/2010 12:15 PM, Tom Lane wrote:
>>> Some examination of
>>> http://www.xmlsoft.org/XSLT/tutorial/libxslttutorial.html
>>> suggests that the parameter values need to be single-quoted,
>>> and indeed when I change the last part of your example
Andrew Dunstan writes:
> On 08/06/2010 12:15 PM, Tom Lane wrote:
>> Some examination of
>> http://www.xmlsoft.org/XSLT/tutorial/libxslttutorial.html
>> suggests that the parameter values need to be single-quoted,
>> and indeed when I change the last part of your example to
>>
>> 'n1=''v1'',n2=''v
On 08/06/2010 12:15 PM, Tom Lane wrote:
Some examination of
http://www.xmlsoft.org/XSLT/tutorial/libxslttutorial.html
suggests that the parameter values need to be single-quoted,
and indeed when I change the last part of your example to
'n1=''v1'',n2=''v2'',n3=''v3'',n4=''v4'',n5=''v5
Hello
attached updated patch with regression test
2010/8/6 Tom Lane :
> Mike Fowler writes:
>> SELECT
>> xslt_process( ... , ... ,
>> 'n1=v1,n2=v2,n3=v3,n4=v4,n5=v5'::text)
>
> produces
>
>>
>> v1
>> v2
>> v3
>> v4
>> v5
>>
>
>> Sadly I get the following in both v
Mike Fowler writes:
> SELECT
> xslt_process( ... , ... ,
> 'n1=v1,n2=v2,n3=v3,n4=v4,n5=v5'::text)
produces
>
>v1
>v2
>v3
>v4
>v5
>
> Sadly I get the following in both versions:
>
>
>
>
>
>
>
Some examination of
http://www.xmlsoft.org/X
On 06/08/10 15:08, Andrew Dunstan wrote:
On 08/06/2010 02:29 AM, Pavel Stehule wrote:
2010/8/6 David Fetter:
On Fri, Aug 06, 2010 at 05:57:37AM +0200, Pavel Stehule wrote:
2010/8/6 Andrew Dunstan:
On 08/05/2010 06:56 PM, Mike Fowler wrote:
SELECT
xslt_process('cim30400'::text,
$$http://
On 08/06/2010 02:29 AM, Pavel Stehule wrote:
2010/8/6 David Fetter:
On Fri, Aug 06, 2010 at 05:57:37AM +0200, Pavel Stehule wrote:
2010/8/6 Andrew Dunstan:
On 08/05/2010 06:56 PM, Mike Fowler wrote:
SELECT
xslt_process('cim30400'::text,
$$http://www.w3.org/1999/XSL/Transform";
version="1.0"
2010/8/6 David Fetter :
> On Fri, Aug 06, 2010 at 05:57:37AM +0200, Pavel Stehule wrote:
>> 2010/8/6 Andrew Dunstan :
>> > On 08/05/2010 06:56 PM, Mike Fowler wrote:
>> >> SELECT
>> >> xslt_process('cim30400'::text,
>> >> $$http://www.w3.org/1999/XSL/Transform";
>> >> version="1.0">
>> >>
>> >>
>>
On Fri, Aug 06, 2010 at 05:57:37AM +0200, Pavel Stehule wrote:
> 2010/8/6 Andrew Dunstan :
> > On 08/05/2010 06:56 PM, Mike Fowler wrote:
> >> SELECT
> >> xslt_process('cim30400'::text,
> >> $$http://www.w3.org/1999/XSL/Transform";
> >> version="1.0">
> >>
> >>
> > [snip]
> >>
> >> $$::text, 'n1=v
2010/8/6 Andrew Dunstan :
>
>
> On 08/05/2010 06:56 PM, Mike Fowler wrote:
>>
>> SELECT
>> xslt_process('cim30400'::text,
>> $$http://www.w3.org/1999/XSL/Transform";
>> version="1.0">
>>
>>
> [snip]
>>
>> $$::text, 'n1=v1,n2=v2,n3=v3,n4=v4,n5=v5'::text)
>>
>>
>
> I haven't been paying attention to
On 08/05/2010 06:56 PM, Mike Fowler wrote:
SELECT
xslt_process('cim30400'::text,
$$http://www.w3.org/1999/XSL/Transform";
version="1.0">
[snip]
$$::text, 'n1=v1,n2=v2,n3=v3,n4=v4,n5=v5'::text)
I haven't been paying attention to this, so sorry if this has been
discussed before, but
2010/8/6 Mike Fowler :
> Hi Pavel,
>
> On 02/08/10 09:21, Pavel Stehule wrote:
>>
>> Hello
>>
>> 2010/8/2 Mike Fowler:
>>>
>>> Hi Pavel,
>>>
>>> Currently your patch isn't applying to head, from the looks of things a
>>> function signature has changed. Can you update your patch please?
>>>
>>
>> ye
Hi Pavel,
On 02/08/10 09:21, Pavel Stehule wrote:
Hello
2010/8/2 Mike Fowler:
Hi Pavel,
Currently your patch isn't applying to head, from the looks of things a
function signature has changed. Can you update your patch please?
yes - see attachment
Thanks, the new patch applies cleanly. H
Hello
2010/8/2 Mike Fowler :
> Hi Pavel,
>
> Currently your patch isn't applying to head, from the looks of things a
> function signature has changed. Can you update your patch please?
>
yes - see attachment
> Also, having had a read through the patch itself I note that there are no
> tests and
Hi Pavel,
Currently your patch isn't applying to head, from the looks of things a
function signature has changed. Can you update your patch please?
Also, having had a read through the patch itself I note that there are
no tests and no changes to documentation. Shouldn't the documentation
adv
64 matches
Mail list logo
