"David E. Wheeler" 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 other.
>> But
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
Florian Pflug 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 table inh
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 b
Dimitri Fontaine writes:
> Tom Lane 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,
Tom Lane 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 already thinking
Richard Huxton 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 restore, ta
Robert Haas writes:
> On Mon, Feb 7, 2011 at 4:18 AM, Dimitri Fontaine
> 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 clause, but
there's at least one big object
On Mon, Feb 7, 2011 at 4:18 AM, Dimitri Fontaine 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 have other reasons for
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
Hi,
Tom Lane 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 stay general enough
On Sun, Feb 6, 2011 at 1:23 PM, 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 time.
>
> Comments?
The design you propose se
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
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.
If we accept it as-is, we'll soon have to rework it, and at that point
we'll be left with
14 matches
Mail list logo
