Hi,
Tom Lane t...@sss.pgh.pa.us writes:
As I work through the extensions patch, the aspect of it that I like the
least is the NO USER DATA clause and related functions. I think it's
badly designed, badly implemented, and doesn't solve the problem.
I'm not loving it either, but wanting to
On 06/02/11 18:23, Tom Lane wrote:
After a bit of thought I believe that we can fix this if we are willing
to teach pg_dump explicitly about extension configuration tables.
The behavior we want for those is for the table schema definition to
never be dumped (the table should always be created by
On Mon, Feb 7, 2011 at 4:18 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Or do you want to keep some generality here?
I think it might be slightly advantageous to keep some generality,
because some people might already have catalog columns that do this
(but with a different name) or might
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 7, 2011 at 4:18 AM, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
Or do you want to keep some generality here?
I think it might be slightly advantageous to keep some generality,
Yeah. I had also thought about hard-wiring the WHERE
Richard Huxton d...@archonet.com writes:
Possible alternative approach?
1. Extension provides list of config tables/views/set-returning
functions to be dumped via e.g. my_config_tables()
2. They get dumped, but each as a TEMP TABLE (need unique names for
multiple extensions though).
3. On
Tom Lane t...@sss.pgh.pa.us writes:
one I'd been thinking about a bit was OIDs of modules this one depends
on. The current design doesn't cope very well with modules that depend
on other ones.
Or even at all. I guess here modules is referring to shared object
libraries, right? Or are you
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
one I'd been thinking about a bit was OIDs of modules this one depends
on. The current design doesn't cope very well with modules that depend
on other ones.
Or even at all. I guess here modules is referring
On Feb6, 2011, at 19:23 , Tom Lane wrote:
After a bit of thought I believe that we can fix this if we are willing
to teach pg_dump explicitly about extension configuration tables.
The behavior we want for those is for the table schema definition to
never be dumped (the table should always be
Florian Pflug f...@phlo.org writes:
We could avoid the need for a per-row system_data flag if we required
extensions to split user-editable and system-provided configuration data
into different tables. For convenient access to the configuration data,
the extension could let the user-editable
On Feb 7, 2011, at 8:57 AM, Tom Lane wrote:
Yeah, this is another approach that one could take instead of having
per-row flags. I'm not sure that it's better, much less so much better
that we should force extensions to do it that way and not the other.
But it's definitely another argument
David E. Wheeler da...@kineticode.com writes:
On Feb 7, 2011, at 8:57 AM, Tom Lane wrote:
Yeah, this is another approach that one could take instead of having
per-row flags. I'm not sure that it's better, much less so much better
that we should force extensions to do it that way and not the
On Feb 6, 2011, at 10:23 AM, Tom Lane wrote:
I've not attempted to implement this idea, but offhand it looks like
it would take a day or two's work, which seems well worthwhile to
expend now in the hope of getting this feature right the first tim
Seems worthwhile, and a much better approach.
On Sun, Feb 6, 2011 at 1:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I've not attempted to implement this idea, but offhand it looks like
it would take a day or two's work, which seems well worthwhile to
expend now in the hope of getting this feature right the first time.
Comments?
The design
13 matches
Mail list logo
