That this family of functions did not exist earlier was merely an
oversight.
Signed-off-by: Abhijit Menon-Sen
---
doc/src/sgml/func.sgml | 28
src/backend/utils/adt/acl.c | 210 ++
src/include/catalog/pg_proc.h| 13
On Mar 29, 2009, at 10:08 PM, Josh Berkus wrote:
Due to budget constraints, Google needed to cut 50 projects from the
Summer of Code this year. We were one of the projects cut (although
we
can re-apply next year).
Leslie at Google has asked me to clarify this. We *also* made a
mistake
Due to budget constraints, Google needed to cut 50 projects from the
Summer of Code this year. We were one of the projects cut (although we
can re-apply next year).
Leslie at Google has asked me to clarify this. We *also* made a mistake
on our application which disqualified us.
--Josh
--
Andrew Gierth writes:
> This one is simpler and works on 8.2 as well:
Yeah, I had just finished making the same adjustment to get an
8.2-compatible test case. 8.1 and before should be okay because
they haven't got the MinimalTuple business.
regards, tom lane
--
Sent vi
> "Tom" == Tom Lane writes:
>>> Yup, fails the same way on an --enable-cassert build of 8.3.7.
And on 8.2.13.
Tom> Do you have a quick test case? I just finished coding up my
Tom> plan-C fix, and I need some test cases ...
Andrew> This is the one I've been using:
This one is simpler
Hi,
On Fri, Mar 27, 2009 at 9:49 PM, Heikki Linnakangas
wrote:
> Uh oh, that's going to be quite tricky with signals. Remember that
> pg_standby is called for each file. A trigger file persists until it's
> deleted, but a signal will only be received by the pg_standby instance that
> happens to b
Bruce Momjian wrote:
> Yea, this is beyond the detail we normally put in the TODO list. If we
> want to add this I am afraid we will need to document other optimizer
> items as well.
FWIW you could just add all that text to a subpage of Todo, and point to
it from the regular TODO item. For exam
> "Tom" == Tom Lane writes:
Tom> Andrew Gierth writes:
>> Yup, fails the same way on an --enable-cassert build of 8.3.7.
Tom> Do you have a quick test case? I just finished coding up my
Tom> plan-C fix, and I need some test cases ...
This is the one I've been using:
create or replace
Andrew Gierth writes:
> Yup, fails the same way on an --enable-cassert build of 8.3.7.
Do you have a quick test case? I just finished coding up my plan-C
fix, and I need some test cases ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
Folks,
Robert Treat brought this up.
I create a table with something to partition by, and some meaningless
junk. I'm trying to get a random ordering inside each window:
CREATE TABLE foo(i, t) AS
SELECT i, md5((i*generate_series(1,10))::text) /* Nonsense text */
FROM generate_series(10,1) i;
SE
> "Tom" == Tom Lane writes:
Tom> Yeah, good point. However I think that you could still get a
Tom> failure. The cases where a slot might contain a minimal tuple
Tom> are generally where we are reading out of a tuplestore or
Tom> tuplesort object, and all you have to do to get it to be a
> "Tom" == Tom Lane writes:
>> For example, given some function foo(out a text, out b text) returning
>> setof record, the query select t.a, t from foo() t; follows the
>> sequence of events you describe, but it doesn't fail because
>> slot-> tts_shouldFree is false, so the original minim
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> In principle there ought to be a whole lot of bugs around this
> Tom> area, because ExecFetchSlotTuple, ExecFetchSlotMinimalTuple, and
> Tom> ExecFetchSlotTupleDatum all are potentially destructive of the
> Tom> original slot contents;
> "Tom" == Tom Lane writes:
Tom> What is happening is that ExecProject fetches the Datum value of
Tom> t2.path from a TupleTableSlot that contains a "minimal tuple"
Tom> fetched from the tuplestore associated with the CTE "t". Then,
Tom> it fetches the value of the whole-row variable t2.
Tom Lane wrote:
> I actually was expecting the above example to show me the user function,
> which I was then going to rant about being a lie. But the actual
> behavior is even worse than that.
>
> There is not anything that is not broken about HEAD's behavior,
> and the sooner we admit that the
In CVS HEAD, try this in an assert-enabled build:
CREATE TEMPORARY TABLE tree(
id INTEGER PRIMARY KEY,
parent_id INTEGER REFERENCES tree(id)
);
INSERT INTO tree
VALUES (1, NULL), (2, 1), (3,1), (4,2), (5,2), (6,2), (7,3), (8,3),
(9,4), (10,4)
Tom Lane wrote:
> Bruce Momjian writes:
> > Andrew Chernow wrote:
> >> Adding PQinitSSL(new_value) seem reasonable to me. My only complaint
> >> has been that the API user has no way of knowing if the function
> >> understood their request.
>
> > I think doing PQinitSSL(new_value) is probably
Tom Lane wrote:
I personally would be happy with the two-argument function solution.
The patch I submitted pretty much does this, except it uses a flags argument
instead of 2 fixed arguments. It can be easily changed to support the 2
argument idea:
1. Change prototype to: void PQinitSecu
Bruce Momjian writes:
> Andrew Chernow wrote:
>> Adding PQinitSSL(new_value) seem reasonable to me. My only complaint
>> has been that the API user has no way of knowing if the function
>> understood their request.
> I think doing PQinitSSL(new_value) is probably the least invasive change
> to
Robert Haas writes:
> I think you should reconsider your non-buying of that argument. That
> would be really, really annoying for me. Most of the time I want to
> look at a user object. But every now and then I want to look at a
> system object.
I still think that this argument is fundamentall
Hitoshi Harada writes:
> 2009/3/29 Tom Lane :
>> ... What might be a bit saner is to remember the slot last passed to
>> tuplestore_gettupleslot for each read pointer. The implication would be
>> that we'd be assuming only one slot is used to fetch from any one read
>> pointer, but that is probab
2009/3/29 Tom Lane :
> Hitoshi Harada writes:
>> So I tried pass EState.es_tupleTables to tuplestore_begin_heap() to
>> trace those TupleTableSlots. Note that if you pass NULL the behavior
>> is as before so nothing's broken. Regression passes but I'm not quite
>> sure EState.es_tupleTable is only
Hello
I am sending samples of transformation hook modules. One module is
JSON support:.
>From these modules only JSON support has general usage - so only JSON
should be integrated to core.
Regards
Pavel Stehule
=== README ===
JSON generating functions - this module contains functions, that allo
On Sat, Mar 28, 2009 at 11:05 PM, Bruce Momjian wrote:
> Based on mentions of his name in previous release notes, you are
> correct; change committed.
Thanks Bruce.
--
Guillaume
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
24 matches
Mail list logo
