Re: Initial review of xslt with no limits patch

Поиск
Список
Период
Сортировка
От David E. Wheeler
Тема Re: Initial review of xslt with no limits patch
Дата
Msg-id 31C839ED-545B-4D3F-BC31-04B0C4748114@kineticode.com
обсуждение исходный текст
Ответ на Re: Initial review of xslt with no limits patch  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: Initial review of xslt with no limits patch  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Initial review of xslt with no limits patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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. 

>> 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,
Idon't think you're going to get too far. 

Best,

David



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: GROUPING SETS revisited
Следующее
От: Gordon Shannon
Дата:
Сообщение: Re: Surprising dead_tuple_count from pgstattuple