On Mon, Jan 16, 2012 at 4:56 PM, Daniel Farina wrote:
> I have been working with xlogdump and noticed that unfortunately it
> cannot be installed without access to a postgres build directory,
> which makes the exported functionality in src/include/utils/pg_crc.h
> useless unless one h
On Mon, Jan 16, 2012 at 6:18 PM, Robert Haas wrote:
> I think you make a compelling case.
That's enough for me to just do it. Expect a patch soon.
--
fdr
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailp
On Sun, Nov 29, 2009 at 6:35 PM, Jeff Davis wrote:
> What if the network buffer is flushed in the middle of a line? Is that
> possible, or is there a guard against that somewhere?
What do you mean? They both catenate onto one stream of bytes, it
shouldn't matter where the flush boundaries are...
On Mon, Nov 30, 2009 at 12:14 PM, Greg Smith wrote:
> Jeff Davis wrote:
>
> COPY target FROM FUNCTION foo() WITH RECORDS;
>
>
> In what format would the records be?
As a not-quite aside, I think I have a better syntax suggestion. I
have recently been digging around in the grammar with the change
On Sun, Dec 6, 2009 at 9:04 AM, Greg Smith wrote:
> And that won't work at all. "Buffer" is a structure, not an integer. You
> need to wait until it's been locked, then save the same data as on the read
> side (relation and block number) from inside the structure. You probably
> want to hook Fl
2009/12/7 黄晓骋 :
> Hello,
>
> I think in Postgresql, concurrency control acts like this:
>
> tuple's infomask shows if it is being updated. If it is being updated now,
> the latter transaction should reread the tuple and get the newer tuple.
> During the progress of getting the newer tuple, it must
On Tue, Dec 29, 2009 at 5:57 PM, Robert Haas wrote:
> I am very fuzzy on where we stand with this patch. There's a link to
> the initial version on the commitfest application, but there has been
> so much discussion since then that I think there are probably some
> revisions to be made, though I
On Tue, Dec 29, 2009 at 6:48 PM, Robert Haas wrote:
> I think there's clear support for a version of COPY that returns rows
> like a SELECT statement, particularly for use with CTEs. There seems
> to be support both for a mode that returns text[] or something like it
> and also for a mode that re
On Tue, Dec 29, 2009 at 8:11 PM, Robert Haas wrote:
> It might be possible to do this without introducing a notion of an
> explicit object, but there are a couple of problems with that. First,
> it requires the user to specify a lot of details on every COPY
> invocation, which is awkward. Second
On Tue, Dec 29, 2009 at 9:11 PM, Robert Haas wrote:
> I think we should try to put an interface layer in place in the first
> iteration. I don't really see this as having much value without that.
> If we implement this strictly as a series of COPY options, we're
> going to be committed to suppor
On Tue, Dec 29, 2009 at 9:46 PM, Robert Haas wrote:
> Sure. If you think you can make it work using bytea, that seems
> clearly better than using an internal type, all things being equal.
I think both are perfectly viable and can be supported simultaneously,
actually...I simply like INTERNAL bec
QL project. The copyright owner is Truviso, Inc in 2009.
Daniel Farina (4):
Add "COPY ... TO FUNCTION ..." support
Add tests for "COPY ... TO FUNCTION ..."
Add dblink functions for use with COPY ... TO FUNCTION ...
Add tests to dblink covering use of COPY T
-- since the dblink connection is still in the COPY state, one
-- can even copy some more data in multiple steps...
COPY bar_2 TO FUNCTION dblink_copy_write;
SELECT dblink_copy_end();
finally:
SELECT dblink_copy_reset('myconn');
Signed-off-by: Dani
Signed-off-by: Daniel Farina
---
src/test/regress/input/copy.source | 38 +++
src/test/regress/output/copy.source | 69 +++
src/test/regress/regress.c | 56
3 files changed, 163 insertions(+), 0
y computing the
FunctionCallInfo once and then reusing it, as opposed to simply
using one of the convenience functions in the fmgr.
- Add and expose the makeNameListFromRangeVar procedure to
src/catalog/namespace.c, the inverse of makeRangeVarFromNameList.
Signed-off-by: Daniel Farina
---
Signed-off-by: Daniel Farina
---
contrib/dblink/expected/dblink.out | 272
contrib/dblink/sql/dblink.sql | 112 +++
2 files changed, 384 insertions(+), 0 deletions(-)
diff --git a/contrib/dblink/expected/dblink.out
b/contrib/dblink
On Mon, Nov 23, 2009 at 2:16 PM, Robert Haas wrote:
> On Mon, Nov 23, 2009 at 4:34 PM, Daniel Farina wrote:
>> Signed-off-by: Daniel Farina
>
> Thanks for the patch. You may want to take a look at this:
>
> http://wiki.postgresql.org/wiki/Submitting_a_Patch
>
> I&#
On Mon, Nov 23, 2009 at 3:46 PM, Andrew Dunstan wrote:
> I recently found myself trying to push data through dblink() and ended up
> writing code to make a call to the target to call a function which called
> back to the source to select the data and insert it. The speedup was
> massive, so I'll b
On Mon, Nov 23, 2009 at 4:03 PM, Daniel Farina wrote:
> Yes. Take a look at the tests introduced to core PostgeSQL (see patch
> 2), where instead of returning a text[] I return just a single text of
> the verbatim output of the copy. You could imagine making that an SRF
> instea
On Mon, Nov 23, 2009 at 4:20 PM, Tom Lane wrote:
> pgsql-hackers had some preliminary discussions a couple months back
> on refactoring COPY to allow things like this --- see the thread
> starting here:
> http://archives.postgresql.org/pgsql-hackers/2009-09/msg00486.php
> While I don't think we ar
On Tue, Nov 24, 2009 at 12:29 AM, Hannu Krosing wrote:
> COPY stdin TO udf();
If stdin becomes (is?) a legitimate source of records, then this patch
will Just Work.
The patch is already quite useful in the COPY (SELECT ...) TO FUNCTION
... scenario.
> COPY udf() FROM stdin;
This is unaddressed
On Tue, Nov 24, 2009 at 12:38 AM, Hannu Krosing wrote:
> COPY func(rowtype) FROM stdin;
I didn't consider rowtype...I did consider a type list, such as:
COPY func(typea, typeb, typec) FROM ...
Which would then operate just like a table, but be useless for the
data-cleaning case, and would not a
On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule wrote:
> Hello
>
> I thing, so this patch is maybe good idea. I am missing better
> function specification. Specification by name isn't enough - we can
> have a overloaded functions. This syntax doesn't allow to use explicit
> cast - from my personal
On Tue, Nov 24, 2009 at 2:50 AM, Hannu Krosing wrote:
> Can't you use existing aggregate function design ?
>
> CREATE AGGREGATE name ( input_data_type [ , ... ] ) (
> SFUNC = sfunc,
> STYPE = state_data_type
> [ , FINALFUNC = ffunc ]
> [ , INITCOND = initial_condition ]
> [ , SORTOP
On Tue, Nov 24, 2009 at 2:51 AM, Daniel Farina wrote:
> On Tue, Nov 24, 2009 at 2:50 AM, Hannu Krosing wrote:
>> Can't you use existing aggregate function design ?
>>
>> CREATE AGGREGATE name ( input_data_type [ , ... ] ) (
>> SFUNC = sfunc,
>> STYPE
On Tue, Nov 24, 2009 at 3:25 AM, Hannu Krosing wrote:
> On Tue, 2009-11-24 at 02:56 -0800, Daniel Farina wrote:
>> On Tue, Nov 24, 2009 at 2:51 AM, Daniel Farina wrote:
>> > On Tue, Nov 24, 2009 at 2:50 AM, Hannu Krosing
>> > wrote:
>> >> Can'
On Tue, Nov 24, 2009 at 4:37 AM, Pavel Stehule wrote:
> 2009/11/24 Daniel Farina :
>> On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule
>> wrote:
>>> Hello
>>>
>>> I thing, so this patch is maybe good idea. I am missing better
>>> function specifi
On Tue, Nov 24, 2009 at 8:45 PM, Pavel Stehule wrote:
> It depends on design. I don't thing so internal is necessary. It is
> just wrong design.
Depends on how lean you want to be when doing large COPY...right now
the cost is restricted to having to call a function pointer and a few
branches. If
On Tue, Nov 24, 2009 at 9:13 PM, Jeff Davis wrote:
>
> I still don't see any reason to force it to be record by record though.
> If the point is to push data from a table into a remote table, why
> should the copied data be translated out of binary format into a record,
> and then back into binar
On Tue, Nov 24, 2009 at 9:35 PM, Pavel Stehule wrote:
> 2009/11/25 Daniel Farina :
>> On Tue, Nov 24, 2009 at 8:45 PM, Pavel Stehule
>> wrote:
>>> It depends on design. I don't thing so internal is necessary. It is
>>> just wrong design.
>>
>> D
On Tue, Nov 24, 2009 at 10:23 PM, Jeff Davis wrote:
> On Wed, 2009-11-25 at 06:35 +0100, Pavel Stehule wrote:
>> I believe so using an "internal" minimalize necessary changes in COPY
>> implementation. Using a funcapi needs more work inside COPY - you
>> have to take some functionality from COPY
On Tue, Nov 24, 2009 at 10:39 PM, Pavel Stehule wrote:
> yes - it is two features - and should be solved independently
There are some common problems though. I was thinking about this with
some mind towards my existing mental model of thinking of specifying
some parameters up-front and getting a
On Wed, Nov 25, 2009 at 9:35 PM, Andrew Dunstan wrote:
> On Wed, November 25, 2009 3:56 pm, Jeff Davis wrote:
>>
>> I worry that we're getting further away from the original problem. Let's
>> allow functions to get the bytes of data from a COPY, like the original
>> proposal. I am not sure COPY is
On Thu, Nov 26, 2009 at 6:13 PM, David Fetter wrote:
> It'd be nice to make this available to the next revision of DBI-Link
> and it'll be pretty handy for our SQL/MED whenever that happens.
Okay, so this thread sort of wandered into how we could refactor other
elements of COPY. Do we have a goo
401 - 434 of 434 matches
Mail list logo
