On Fri, Apr 12, 2013 at 1:07 PM, Hannu Krosing ha...@2ndquadrant.comwrote:
I was just thinking of moving the queries the pg_dump currently
uses into UDF-s, which do _not_ use catalog cache, but will use
the same SQL to query catalogs as pg_dump currently does
using whatever snapshot mode is
Tom Lane t...@sss.pgh.pa.us writes:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
This idea doesn't work because of back-patch considerations (i.e. we
would not be able to create the functions in back branches, and so this
new style of pg_dump would only work with future server versions).
Michael Paquier michael.paqu...@gmail.com writes:
I recall discussions about reverse engineering of a parsed query tree in
the event trigger threads but nothing has been committed I think. Also, you
Yes. The name used in there was Normalized Command String.
need to consider that implementing
On 04/11/2013 11:48 PM, Andrew Dunstan wrote:
It could be interesting to have a library that would output database
metadata in some machine readable and manipulatable format such as
JSON or XML. One thing that's annoying about the text output pg_dump
produces is that it's not at all
On 04/11/2013 12:17 AM, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Hannu Krosing wrote:
Natural solution to this seems to move most of pg_dump functionality
into backend as functions, so we have pg_dump_xxx() for everything
we want to dump plus a topological sort function
Pavel Golub pa...@microolap.com writes:
From my point of view the new library should export only two
functions:
1. The execution function:
ExecStatusType PGdumpdbParams(const char * const *keywords,
const char * const *values);
No, this is exactly *wrong*. You might as
Hello, Tom.
You wrote:
TL Pavel Golub pa...@microolap.com writes:
From my point of view the new library should export only two
functions:
1. The execution function:
ExecStatusType PGdumpdbParams(const char * const *keywords,
const char * const *values);
TL No, this is
On 04/11/2013 09:51 AM, Tom Lane wrote:
Pavel Golub pa...@microolap.com writes:
From my point of view the new library should export only two
functions:
1. The execution function:
ExecStatusType PGdumpdbParams(const char * const *keywords,
const char * const *values);
No,
* Andrew Dunstan (and...@dunslane.net) wrote:
On 04/11/2013 09:51 AM, Tom Lane wrote:
No, this is exactly *wrong*. You might as well not bother to refactor,
if the only API the library presents is exactly equivalent to what you
could get with system(pg_dump ...).
Agreed.
Well, either they
On Fri, Apr 12, 2013 at 1:00 AM, Stephen Frost sfr...@snowman.net wrote:
Well, either they want that or they want that output more
accessibly, and without all the baggage that pg_dump necessarily
brings to the table. pg_dump does a lot of stuff that's basically
designed for bulk
Well, either they want that or they want that output more
accessibly, and without all the baggage that pg_dump necessarily
brings to the table. pg_dump does a lot of stuff that's basically
designed for bulk operations, and often what people want is a way to
get, say, the creation DDL for
On 4/10/13 10:54 AM, ˧ wrote:
I'm interested in the idea Rewrite (add) pg_dump and pg_restore
utilities as libraries (.so, .dll .dylib).
The pg_dump code is a giant mess, and refactoring it as a library is
perhaps not a project for a new hacker.
Independent of that, I think the first
Peter Eisentraut wrote:
I think the main uses cases mentioned in connection with this idea are
usually in the direction of finer-grained control over what gets dumped
and how. But making pg_dump into a library would not necessarily
address that.
There's also the matter of embedding pg_dump
On 04/10/2013 11:02 PM, Alvaro Herrera wrote:
Peter Eisentraut wrote:
I think the main uses cases mentioned in connection with this idea are
usually in the direction of finer-grained control over what gets dumped
and how. But making pg_dump into a library would not necessarily
address that.
Hannu Krosing wrote:
On 04/10/2013 11:02 PM, Alvaro Herrera wrote:
Peter Eisentraut wrote:
I think the main uses cases mentioned in connection with this idea are
usually in the direction of finer-grained control over what gets dumped
and how. But making pg_dump into a library would not
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Hannu Krosing wrote:
Natural solution to this seems to move most of pg_dump functionality
into backend as functions, so we have pg_dump_xxx() for everything
we want to dump plus a topological sort function for getting the
objects in right order.
Hello, 帅.
You wrote:
帅 Hi all,
帅 I'd like to introduce myself to the dev community. I am Shuai
帅 Fan, a student from Dalian University of Technology, DLUT , for
帅 short, China. And I am interested in working with PostgreSQL project in
GSOC2013.
帅 I'm interested in the idea Rewrite
17 matches
Mail list logo
