Hello
When I worked on parametrised DO statement, I had to solve following issue:
Syntax is:
DO (param list) $$ ... $$ LANGUAGE ... USING expr_list
What is correct way for evaluation of expr_list with specified target types?
I used two techniques:
1) evaluation expressions -
http://archives.p
On Saturday, July 7, 2012, Tom Lane wrote:
>
> If we think that operators outside of extensions will be an infrequent
> special case, what about just dumping all of them into a single file
> named "operators"? And similarly for casts?
>
> regards, tom lane
>
+1
Pavel Stehule writes:
> When I worked on parametrised DO statement, I had to solve following issue:
> Syntax is:
> DO (param list) $$ ... $$ LANGUAGE ... USING expr_list
> What is correct way for evaluation of expr_list with specified target types?
I'd argue that that's a pointlessly unwieldy
2012/7/8 Tom Lane :
> Pavel Stehule writes:
>> When I worked on parametrised DO statement, I had to solve following issue:
>
>> Syntax is:
>
>> DO (param list) $$ ... $$ LANGUAGE ... USING expr_list
>
>> What is correct way for evaluation of expr_list with specified target types?
>
> I'd argue tha
On lör, 2012-07-07 at 11:32 -0400, Aidan Van Dyk wrote:
> But, since you're using operators, what would you think is an
> appropriate name for the file the operator is dumped into?
The name of the operator, just like for any other object. (Assuming
we're using the name of a table for the file for
On lör, 2012-07-07 at 17:18 -0400, Tom Lane wrote:
> Sure. You need not look further than "/" to find an operator name that
> absolutely *will* cause trouble if it's dumped into a filename
> literally.
But that problem applies to all object names.
> If we think that operators outside of extensio
Robert Haas writes:
> On Jul 7, 2012, at 1:46 PM, Tom Lane wrote:
>> 3. Try another approach entirely. The idea that I've got in mind here
>> is to compile the regex using the regex library and then look at the
>> compiled NFA representation to see if there must be a fixed prefix.
> I think thi
Peter Eisentraut writes:
> On lör, 2012-07-07 at 17:18 -0400, Tom Lane wrote:
>> Sure. You need not look further than "/" to find an operator name that
>> absolutely *will* cause trouble if it's dumped into a filename
>> literally.
> But that problem applies to all object names.
In principle,
>>> Tatsuo Ishii writes:
> So far as I can see, the only LCPRVn marker code that is actually in
> use right now is 0x9d --- there are no instances of 9a, 9b, or 9c
> that I can find.
>
> I also read in the xemacs internals doc, at
> http://www.xemacs.org/Documentation/21.5
2012/7/5 Shigeru HANADA :
>> In addition, is pull_var_clause() reasonable to list up all the attribute
>> referenced at the both expression tree? It seems to be pull_varattnos()
>> is more useful API in this situation.
>
> Only for searching, yes. However, sooner or later we need Var o
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
>> Also, I was under the impression that recent Linux kernels use hugepages
>> automatically if they can, so I wonder exactly what Andres was testing
>> on ...
> if you mean the "trasparent hugepage" feature, iirc it doesn't affect
> MAP_SHARED map
11 matches
Mail list logo
