I've reviewed quickly. I'll need more time to
look in detail, but I'd like more inputs for the high-level design and
direction.
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Jan 21, 2012 at 9:20 AM, Dimitri Fontaine
wrote:
> Hi,
>
> Thank you for reviewing this patch!
>
> Hitoshi Harada writes:
>> The patch applies with one reject, which I could fix easily. The make
>> check passed.
>
> Bitrot happens fast in this season… wi
On Mon, Jan 23, 2012 at 2:00 AM, Dimitri Fontaine
wrote:
> Hitoshi Harada writes:
>>>> - What happens if DROP EXTENSION ... CASCADE? Does it work?
>>>
>>> It should, what happens when you try? :)
>>
>> I just tried DROP EXTENSION now, and found it
On Thu, Jan 19, 2012 at 1:58 AM, Hitoshi Harada wrote:
> On Wed, Jan 18, 2012 at 1:11 AM, Hitoshi Harada wrote:
>> On Sat, Jan 14, 2012 at 8:10 AM, Matthew Draper wrote:
>>>
>>> I just remembered to make time to advance this from WIP to proposed
>>> patch
On Mon, Jan 23, 2012 at 7:13 PM, Matthew Draper wrote:
> On 19/01/12 20:28, Hitoshi Harada wrote:
>>> (Now it occurred to me that forgetting the #include parse_func.h might
>>> hit this breakage..., so I'll fix it here and continue to test, but if
>>> you'
On Sun, Jan 29, 2012 at 1:08 AM, Matthew Draper wrote:
> On 25/01/12 18:37, Hitoshi Harada wrote:
>>> I'm still not sure whether to just revise (almost) all the SQL function
>>> examples to use parameter names, and declare them the "right" choice; as
>>
On Thu, Feb 2, 2012 at 3:19 PM, Tom Lane wrote:
> [ working on this patch now ... ]
>
> Matthew Draper writes:
>> On 25/01/12 18:37, Hitoshi Harada wrote:
>>> Should we throw an error in such ambiguity? Or did you make it happen
>>> intentionally? If latter, w
On Mon, Jan 23, 2012 at 3:06 AM, Hitoshi Harada wrote:
> On Mon, Jan 23, 2012 at 2:00 AM, Dimitri Fontaine
> wrote:
>> Hitoshi Harada writes:
>>>>> - What happens if DROP EXTENSION ... CASCADE? Does it work?
>>>>
>>>> It should, what happens w
e 3 % gain by this change.
Correct me as I'm probably wrong.
Anyway, it's nice to modify the comment just above the change, since
it's now true with it.
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t around the limitation. It shows a 2 fold
> improvement when indexing an integer column on a 50,000,000 row
> randomly ordered table.
In any case, we do need bird-eye sketch to attack it but I guess it's
worth and at some future point we definitely must do, though I don't
know if it&#
On Sat, Feb 11, 2012 at 11:34 AM, Jeff Janes wrote:
> On Wed, Feb 8, 2012 at 1:01 AM, Hitoshi Harada wrote:
>> On Sun, Jan 15, 2012 at 4:59 PM, Jeff Janes wrote:
>>>
>>> The attached patch allows it to reuse that memory. On my meager
>>> system it reduced th
On Mon, Feb 13, 2012 at 3:18 AM, Dimitri Fontaine
wrote:
> Hi,
>
> Sorry for the delays, I'm back on PostgreSQL related work again.
>
> Hitoshi Harada writes:
>>>> I just tried DROP EXTENSION now, and found it broken :(
>
> Please find v2 of the patch. I d
On Fri, Feb 24, 2012 at 2:09 PM, Dimitri Fontaine
wrote:
> Hitoshi Harada writes:
>> I confirmed DROP EXTENSION is fixed now. In turn, it seems to me
>> "requires" doesn't work. My test ext2.control looks like:
>
> I'm very sorry about that. It'
whose name is the same as other base type. Is it intentional?
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
input, we can continue the rest
of work.
Anyway the memory usage problem is not only array_agg and hash
aggregate. Even if you can say the hash table exceeds X% of the
work_mem, how can you tell other operators such like Sort are not
using the rest of memory? One approach I could see to avoid this is
and other patches, but
it seems to me that the quality of both of the design and patch code
are not adequate at this point of time. I think I agree we are not
100% happy with the current dependency system of extensions, but we
need more time to think and make it mature idea rather than rushing
and pushing and dropping something premature. The cost we would pay
if we rushed this to this release will be higher than what we'd get
from it, I think.
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Mar 29, 2012 at 12:51 AM, Dimitri Fontaine
wrote:
> Hitoshi Harada writes:
>> Frankly I'm still against this patch. Since I started to review it
>> I've never been convinced with the use case. Yeah, someone said it'd
>> be useful to him, but as a
multi-phase
aggregate, but in theory the proposal above is state-merge function,
so it doesn't apply to general aggregate results that passed through
the final function. Of course some functions that don't have final
functions are ok to call state-merge function on the results.
Th
ound tcount parameter is said to
be applied to even INSERT. I believe people think that parameter is
to limit memory consumption when returning tuples thus it'd be applied
for only SELECT or DML with RETURNING. So I'm +1 for non-fix but
redefine the behavior. Who wants to limit the num
a good example, which invokes Python from FDW
routines though it is not using PL/Python.
http://multicorn.org/
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
session id rather than
process id for the latter. I don't think SnapshotNow is the problem as
anyway executor is reading catalogs with that today.
Thanks,
Hitoshi
--
Hitoshi Harada
optional builtin so that once the system is initialized the the plugin
should not go away. Anyway pluggable compression is off-topic here.
Thanks,
--
Hitoshi Harada
want to avoid any
> per-tuple allocations.
>
>
I believe WinGetFuncArgInPartition is a bit slow if the offset is far from
the current row. So it might make sense to store the last-seen value, but
I'm not sure if we need to copy datum every time. I haven't looked into
the new patch.
Thanks,
--
Hitoshi Harada
On Tue, Jun 18, 2013 at 1:58 AM, Andres Freund wrote:
> On 2013-06-18 00:56:17 -0700, Hitoshi Harada wrote:
> > On Fri, Jun 14, 2013 at 4:06 PM, Andres Freund >wrote:
> >
> > >
> > > Here's the updated version. It shouldn't contain any obvious WIP p
been done through grouping_planner, and
the parse tree is not necessarily representing the corresponding elements
at this point. I think it'd be better to see path keys to find out the
list of elements that may be removed, rather than SortClause, which would
be a more generalized approach.
Thanks,
--
Hitoshi Harada
don't see big problems in this patch other than how to
manage the pluggability, but it is a WIP patch anyway, so I'm going to mark
it as Returned with Feedback.
Thanks,
--
Hitoshi Harada
tands it doesn't have critical issue, but more
generalized approach would be desirable. That said, I don't have strong
objection to the current patch, and just posting one thought to see if
others may have the same opinion.
Thanks,
--
Hitoshi Harada
immediate shutdown? To me the current immediate
shutdown is reliable, in that it without doubt returns control back to
terminal, after killing postmaster at least.
Thanks,
--
Hitoshi Harada
with 'm', too, not only 'r'?
- I found two additional parameters on make_new_heap ugly, but couldn't
come up with better solution. Maybe we can pass Relation of old heap to
the function instead of Oid..
That's about it from me.
Thanks,
--
Hitoshi Harada
ue' in our catalog. Per spec, RANGE BETWEEN needs
to detect ERROR if the offset value is negative, but it is not always easy
if you think about interval, numeric types as opposed to int64 used in ROWS
BETWEEN.
Thanks,
--
Hitoshi Harada
On Fri, Jun 21, 2013 at 2:20 AM, Hitoshi Harada wrote:
>
>
>
> On Fri, Jun 14, 2013 at 9:05 AM, Kevin Grittner wrote:
>
>> Attached is a patch for REFRESH MATERIALIZED VIEW CONCURRENTLY for
>> 9.4 CF1. The goal of this patch is to allow a refresh without
>>
On Thu, Jun 20, 2013 at 12:19 AM, Etsuro Fujita wrote:
> > From: Hitoshi Harada [mailto:umi.tan...@gmail.com]
>
> > I guess the patch works fine, but what I'm saying is it might be limited
> to
> > small use cases. Another instance of this that I can think of
On Fri, Jun 21, 2013 at 3:20 AM, Craig Ringer wrote:
> On 06/21/2013 05:32 PM, Hitoshi Harada wrote:
>
> > I also later found that we are missing not only notion of '+' or '-',
> > but also notion of 'zero value' in our catalog. Per spec, RANGE
On Tue, Jun 25, 2013 at 9:07 AM, Robert Haas wrote:
> On Fri, Jun 21, 2013 at 5:20 AM, Hitoshi Harada
> wrote:
> > If I don't miss something, the requirement for the CONCURRENTLY option
> is to
> > allow simple SELECT reader to read the matview concurrently while th
On Wed, Jun 26, 2013 at 1:38 AM, Kevin Grittner wrote:
> Hitoshi Harada wrote:
>
> > I spent a few hours to review the patch.
>
> Thanks!
>
> > As far as I can tell, the overall approach is as follows.
> >
> > - create a new temp heap as non-concurrent
ion_template and
pg_extension_control?
- Looks like both tables don't have toast tables. Some experiment gives:
ERROR: row is too big: size 8472, maximum size 8160
Thanks,
--
Hitoshi Harada
On Thu, Jun 27, 2013 at 2:49 AM, Dimitri Fontaine wrote:
> Hi,
>
> Thanks a lot for your review!
>
> Some answers here, new version of the patch with fixes by tuesday.
>
> Hitoshi Harada writes:
> > - create template ex2, create extension ex2, alter template ex
, and you may be confused with #1127, extensible
external toast tuple support.
--
Hitoshi Harada
On Thu, Jun 27, 2013 at 12:19 AM, Hitoshi Harada wrote:
>
>
>
> On Wed, Jun 26, 2013 at 1:38 AM, Kevin Grittner wrote:
>
>>
>
New version attached.
>>
>>
>> Will take another look.
>
>
>
Oops!
drop materialized view if exists mv;
drop table if
y prohibiting the creation of a transform that
> affects functions that already exist.
However I don't see this prohibition of create transform if there is
already such function. You are not planning to address this issue?
For now, that's it. I'm going to dig more later.
Thanks,
Hitoshi Harada
ema is inaccesible and undroppable:
>>
>
> and dropping the extension let the schema around
>
Hm? I guess '123' is not schema, but it's version.
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ng all of these?
>
> I don't see any value in that. The data types they apply to are in
> contrib after all.
>
>
I guess his suggestion is contrib/transforms directory, not transforms
directory at top level. Stil you don't see value?
--
Hitoshi Harada
disk gets full. Or is that operation supposed to
be restricted by the security context you are adding?
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Jul 7, 2013 at 12:06 PM, Peter Eisentraut wrote:
> On Thu, 2013-07-04 at 02:18 -0700, Hitoshi Harada wrote:
>> as someone suggested in the previous thread, it might be a variant of
>> CAST. CREATE CAST (hstore AS plpython2u) ? Or CREATE LANGUAGE TRANSFORM
>> mi
On Thu, Jul 4, 2013 at 2:18 AM, Hitoshi Harada wrote:
> For now, that's it. I'm going to dig more later.
>
After looking into rest of the change,
- TYPTYPE_DOMAIN is not supported. Why did you specifically disallow it?
- ParseFuncOrColumn now prohibits to find function returni
On Sat, Jul 6, 2013 at 9:20 AM, Kevin Grittner wrote:
> Hitoshi Harada wrote:
>
>> Oops!
>
> Indeed. Thanks for the careful testing.
>
>> drop materialized view if exists mv;
>> drop table if exists foo;
>> create table foo(a, b) as values(1, 10);
>>
On Tue, Jul 9, 2013 at 12:50 PM, Kevin Grittner wrote:
>
> Thanks again! New patch attached.
>
After a couple of more attempts trying to break it, I mark this as
ready to go. One small question: why do we use multiple unique
indexes if exist? One index isn't enough?
--
xPredicate(indexRel) != NIL)
{
index_close(indexRel, NoLock);
ReleaseSysCache(indexTuple);
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
+ * CreateSharedInvalidationState
* Create and initialize the SI message buffer
*/
void
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ecial. plv8 also wanted this notion of
"function setting" before introducing find_function(), which natively
loads other JS functions that are defined via CREATE FUNCTION. Of
course it is not optimal, but it turned out it is not terribly slow.
Maybe it depends on language runtime. So f
do like in date_in(). I
think to_date() should follow it because it is the entrance place to
check sanity.
Thanks,
--
Hitoshi Harada
to_date_check.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
ly, I would love to see this in the next release. Good work!
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2010/12/1 Itagaki Takahiro :
> On Wed, Dec 1, 2010 at 12:30, Hitoshi Harada wrote:
>> From a user's view, this is very long way to see a simplest foreign
>> table. I know it is based on the standard, but I really want a
>> shortcut. Especially, I don't underst
coding option to COPY will eliminate
allowEncodingChanges option from JDBC driver.
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
trimming logic is for
something like moving aggregates and (simple) rank(), which grows
tuplestore content as it advances. percent_rank() doesn't seem to
match the optimization.
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2010/12/11 Tom Lane :
> Hitoshi Harada writes:
>> I see it's too late now that you've committed it,
>
> Patches can always be reverted...
>
>> but it seems there
>> was another way to avoid it by not trimming from percent_rank()
>> individually. Once
PIs. APIs change don't harm SQL interfaces. Of course
CREATE FOREIGN TABLE is not useful as alone, but it would be helpful
to be reviewed easily.
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2010/12/13 Shigeru HANADA :
> On Sun, 12 Dec 2010 23:47:53 +0200
> Peter Eisentraut wrote:
>> On ons, 2010-12-01 at 12:30 +0900, Hitoshi Harada wrote:
>> > From a user's view, this is very long way to see a simplest foreign
>> > table. I know it is based o
> implemented. RANGE needed more work; not sure if the patch author is
> working on it.
>
>> 2) If not, how can I help with that?
>
> I think you should ping Hitoshi Harada directly.
I am not working on it right now. It needed new infrastructure in the
core, and KNNGIST might
indexing but avoiding unnecessary seq scan and supporting RANGE
concept may buy somehow.
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2010/12/27 Robert Haas :
> On Sun, Dec 26, 2010 at 2:41 PM, Tom Lane wrote:
>> Hitoshi Harada writes:
>>> Catching up tonight, I wonder I could propose to add ordering
>>> operators in btree, not in gist, for basic types.
>>
>> I thought about that for a
he window functions and PARTITION also
want to represent RANGE but there's no clear solution.
Sorry if it's already been discussed since I didn't track the threads.
Regards
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
2011/1/5 Jeff Davis :
> On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote:
>> > CREATE TYPE numrange
>> > AS RANGE (SUBTYPE=numeric, SUBTYPE_CMP=numeric_cmp);
>>
>> I am interested in how you define increment/decrement operation of
>> range value
2011/1/5 Jeff Davis :
> On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote:
>> > CREATE TYPE numrange
>> > AS RANGE (SUBTYPE=numeric, SUBTYPE_CMP=numeric_cmp);
>>
>> I am interested in how you define increment/decrement operation of
>> range value
together three of KNN-GIST, range type and window
frame issue. For KNN-GIST, it was committed by extending pg_amop
without considering others and range type will be as well. Not getting
them together might be the answer.
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hack
f you need unit case I'll send it, but the
problem seems clear.
Regards,
--
Hitoshi Harada
psql_encoding_bugfix.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2011/1/13 Tom Lane :
> Hitoshi Harada writes:
>> I found a crash case (assertion failure) when runing psql -f
>> utf8_encoded_script.sql against client_encoding = shift_jis in
>> postgresql.conf. Though encoding mismatch is obviously user's fault, a
>> crash
erver/server_to_client(), but the former will surely add
slight overhead per reading line and I believe copy is
performance-sensitive command.
I'll add this to the CF app.
Regards,
--
Hitoshi Harada
copy_encoding.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgs
tical.
I mark "Waiting on Author" for the regression test issue. Other points
are trivial.
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
hon interpreter
* and global data.
*/
is bogus. PLy_init_interp() is called in _PG_init().
That's all for now. Some of them must be my misunderstanding or
trivial, but I post them for the record.
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2011/1/18 Jan Urbański :
> On 17/01/11 09:26, Jan Urbański wrote:
>> On 17/01/11 01:02, Hitoshi Harada wrote:
>>> This is a review for the patch sent as
>>> https://commitfest.postgresql.org/action/patch_view?id=456
>>> It includes adequate amount of test. I
2011/1/19 Jan Urbański :
> On 19/01/11 02:06, Hitoshi Harada wrote:
>> - -1 is used as the initial value of PLyTypeInfo.is_rowtype. Why not 0?
>
> See the comments in struct PLyTypeInfo:
>
> is_rowtype can be: -1 = not known yet (initial state); 0 = scalar
> datatype; 1 = r
out" to identify
>> the stuff that gets removed by the filter, as opposed to what gets
>> through. So we could possibly use "Rows Filtered Out: nnn". I still
>> think that's more awkward than "Rows Removed: nnn" though.
>
> "Rows Skipped: n
after the error.
== Performance ==
I didn't test performance regression. My static code analysis doesn't
tell it has critical performance issue.
I mark this as "Waiting on Author" for the typmod issue.
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list
2011/1/23 Jan Urbański :
> On 22/01/11 11:15, Hitoshi Harada wrote:
>> This is a review for
>> https://commitfest.postgresql.org/action/patch_view?id=460
>
> Thanks,
>
>> One issue is typmod of record type.
>>
>> regression=# create or replace function fu
2011/1/25 Itagaki Takahiro :
> On Sat, Jan 15, 2011 at 02:25, Hitoshi Harada wrote:
>> The patch overrides client_encoding by the added ENCODING option, and
>> restores it as soon as copy is done.
>
> We cannot do that because error messages should be encoded in the ori
lso, try to
create a view on those expressions. I don't think it correctly preserves
it.
Thanks,
--
Hitoshi Harada
ug in 9.2 or an
expected behavior in the new plan cache?
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Sep 14, 2012 at 12:55 PM, Tom Lane wrote:
> Hitoshi Harada writes:
>> I expected success in tname::regclass in the function chck(), but it
>> actually fails for your first run in the session.
>
> Really? Not for me.
>
> In the example as given, I see succe
run ANALYZE first,
but it is too hard for a normal users to use it. We may need
quick-and-rough count(*) for this.
That is pretty much I have so far. I haven't read all the code nor
the standard, so I might be wrong somewhere.
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
) in the same way, it's much nicer than having
additional binary + extension. Isn't it possible to do the same thing
above within the CLUSTER command? Maybe CLUSTER .. CONCURRENTLY?
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
re-defined type or function oid macros, and I guess it is reasonable
for the external developers to hope to do such things.
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
echanism is used throughout postgres already and seems to work
> just fine.
>
Sure, but how do you know the type named "hstore" is what you know as
hstore? We don't have a global consensus a specific type name means
exactly what everyone thinks it is.
Thanks,
--
Hitoshi Hara
ttr(). Of course some #ifdefs can fix that, but it seems
> annoying to make everyone do that. Maybe this could be reconsidered to
> reduce the impact on other projects.
>
But it's only add #include "access/htup_details.h"? I'd not argue
it's harmful unless I missed
+ /* or it may not be what we expected... */
+ if (*str == '\0')
+ return DTERR_BAD_FORMAT;
+
field[nf] = str;
if (isdigit((unsigned char) *str))
{
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pg
On Mon, Oct 1, 2012 at 3:30 PM, Hitoshi Harada wrote:
> lower address than field.
Ugh, s/lower/higher/
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
her solutions?
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Oct 18, 2012 at 8:35 AM, Tom Lane wrote:
> I wrote:
>> Hitoshi Harada writes:
>>> If OOM happens during expand_table() in hash_search_with_hash_value()
>>> for RelationCacheInsert,
>
> the palloc-based allocator does throw
> errors. I think that when
On Fri, Oct 19, 2012 at 11:40 AM, Tom Lane wrote:
> Hitoshi Harada writes:
>> On Thu, Oct 18, 2012 at 8:35 AM, Tom Lane wrote:
>>> I'm not terribly comfortable with trying to use a PG_TRY block to catch
>>> an OOM error - there are too many ways that could bre
2010/2/9 Tom Lane :
> Hitoshi Harada writes:
>> 2010/1/23 Robert Haas :
>>> Would it make sense to pull some of the infrastructure bits out of
>>> this patch and commit those bits separately, so as to reduce the size
>>> of the main patch? In particular, the A
able partitioning with RANGE option maybe?
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2010/2/13 Tom Lane :
> Hitoshi Harada writes:
>> [ more_frame_options patch ]
>
> Committed after rather extensive revisions.
Thanks a lot.
> I'm not terribly happy with the changes you made in WinGetFuncArgInPartition
> and WinGetFuncArgInFrame to force the wind
but I think there are not
enough fundamentals yet. Because we started from defining operators if
they can be "ordered or indexed", general operator semantics is over
them, not adding columns to pg_amop. It will be something like
datatype-independent human word: "add and subtract"
; but that's not really
> project style.)
DirectFunctionCall1/2/3...?
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t be applied if
the function is volatile. Also, I don't see how do you choose function
argument values even in immutable cases.
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
2010/2/16 Pavel Stehule :
> 2010/2/16 Hitoshi Harada :
>> 2010/2/16 Pavel Stehule :
>>> I think, so these problem have to be identified in compile stage - but
>>> it can be too strict for all (and can slow down production) - it is
>>> reason for plugin.
>&
.4, I hope we can
remove the special syntax cases for them by replacing them with normal
variadic functions. Is it sane idea?
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/
e another solution here?
I'm completely against the wrong GROUP BY syntax from MySQL, but it is
also true that SQL is only an interface.
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
n
the function. Isn't it enough to add more parameters for them
(agg_distinct is passed separately) and to leave the Aggref pointer
passing as present?
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
NAME_KEYWORD from COL_NAME_KEYWORD
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
1 - 100 of 443 matches
Mail list logo
