Re: Initial review of xslt with no limits patch - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Initial review of xslt with no limits patch
Date
Msg-id AANLkTikgPbAqfsszQ=VPhoF1xs2N=jh6GDWJyaBPByMV@mail.gmail.com
Whole thread Raw
In response to Re: Initial review of xslt with no limits patch  ("David E. Wheeler" <david@kineticode.com>)
Responses Re: Initial review of xslt with no limits patch
List pgsql-hackers
2010/8/7 David E. Wheeler <david@kineticode.com>:
> 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.
 

no it doesn't - in your design there are no different notation for key
and for value. Next this design block  a '->'. Because it's based on
polymorphic operator. But it can be a one variant - where you would to
put together expr with expr. And you can't do more from user space
now. But if you have a build in operator for (sqlidentifier, any) with
early processing - like "AS" in xml_attributies, we can do it. The
using of this operator can be limited only on function parameter
context.

>
>>> Pavel doesn't understand "no" ;-)
>>
>> you are don't writing a stored procedures like me - so maybe you are
>> doesn't understand a my motivation. :). I have to try it. You are
>> rejected almost of all my proposals - named parameters, variadic
>> functions, enhancing of RAISE STATEMENT - and now its in core. But it
>> was a battle :).
>
> This is how most stuff gets in: you fight Tom to exhaustion. It's a slog, but usually the resulting implementation is
betterthan it would otherwise have been.
 
>
>> Try to write a XML-RPC support for PostgreSQL, and
>> try to thinking on programmer comfort, please. I am sure so our
>> support for stored procedures or external procedures are not complete
>> - it is limited by BISON possibilities, and because BISON isn't
>> extensible parser, I am searching other ways. If I can enhance a
>> syntax from external module, I don't talk.
>
> 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.
 

Postgres has a array of rows (Inside C or plperlu can be transofmed to
real hash simply). It just miss a user friendly notation for using it.

Regards

Pavel
>
> Best,
>
> David
>
>


pgsql-hackers by date:

Previous
From: Gordon Shannon
Date:
Subject: Re: Surprising dead_tuple_count from pgstattuple
Next
From: Tom Lane
Date:
Subject: Re: Initial review of xslt with no limits patch