On Wed, Feb 01, 2012 at 10:02:14PM +0100, Dimitri Fontaine wrote:
> The case for a table that is partly user data and partly extension data
> is very thin, I think that if I had this need I would use inheritance
> and a CHECK(user_data is true/false) constraint to filter the data.
definitely agree
Hi,
Sorry to be late in the thread, I'm too busy right now. Cédric called
it to my immediate attention though.
Martijn van Oosterhout writes:
> Perhaps a better way of dealing with this is providing a way of dumping
> extensions explicitly. Then you could say:
>
> pg_dump --extension=postgis -s
Adrian Klaver writes:
> On 01/31/2012 04:36 AM, Robert Haas wrote:
>> On Mon, Jan 30, 2012 at 11:18 PM, Tom Lane wrote:
>>> What's not apparent to me is whether there's an argument for doing more
>>> than that. It strikes me that the current design is not very friendly
>>> towards the idea of an
On 01/31/2012 04:36 AM, Robert Haas wrote:
On Mon, Jan 30, 2012 at 11:18 PM, Tom Lane wrote:
I don't recall that we thought very hard about what should happen when
pg_dump switches are used to produce a selective dump, but ISTM
reasonable that if it's "user data" then it should be dumped only i
On Mon, Jan 30, 2012 at 11:18:31PM -0500, Tom Lane wrote:
> I don't recall that we thought very hard about what should happen when
> pg_dump switches are used to produce a selective dump, but ISTM
> reasonable that if it's "user data" then it should be dumped only if
> data in a regular user table
On Mon, Jan 30, 2012 at 11:18 PM, Tom Lane wrote:
> I don't recall that we thought very hard about what should happen when
> pg_dump switches are used to produce a selective dump, but ISTM
> reasonable that if it's "user data" then it should be dumped only if
> data in a regular user table would b
[ Note: please follow-up to pgsql-hackers not pgsql-general; I think
this discussion needs to move there ]
hubert depesz lubaczewski writes:
> On Mon, Jan 30, 2012 at 11:30:51AM -0500, Tom Lane wrote:
>> That is way too vague for my taste, as you have not shown the pg_dump
>> options you're usi
On 01/30/2012 09:53 AM, hubert depesz lubaczewski wrote:
On Mon, Jan 30, 2012 at 09:51:58AM -0800, Adrian Klaver wrote:
On 01/30/2012 09:45 AM, hubert depesz lubaczewski wrote:
On Mon, Jan 30, 2012 at 09:43:46AM -0800, Adrian Klaver wrote:
On 01/30/2012 09:23 AM, hubert depesz lubaczewski wrot
On Monday, January 30, 2012 8:25:54 am hubert depesz lubaczewski wrote:
> On Mon, Jan 30, 2012 at 08:20:15AM -0800, Adrian Klaver wrote:
> > I am not sure I understand crippled. There is a bug that you acknowledge
> > has been dealt with. The rest is documented behavior having to do with
> > extens
On Mon, Jan 30, 2012 at 09:51:58AM -0800, Adrian Klaver wrote:
> On 01/30/2012 09:45 AM, hubert depesz lubaczewski wrote:
> >On Mon, Jan 30, 2012 at 09:43:46AM -0800, Adrian Klaver wrote:
> >>On 01/30/2012 09:23 AM, hubert depesz lubaczewski wrote:
> >>
> >>>
> >>>I think I explained it in previous
On 01/30/2012 09:45 AM, hubert depesz lubaczewski wrote:
On Mon, Jan 30, 2012 at 09:43:46AM -0800, Adrian Klaver wrote:
On 01/30/2012 09:23 AM, hubert depesz lubaczewski wrote:
I think I explained it in previous mails, and if not - sorry, but
I clearly can't explain good enough - the point is
On Mon, Jan 30, 2012 at 09:43:46AM -0800, Adrian Klaver wrote:
> On 01/30/2012 09:23 AM, hubert depesz lubaczewski wrote:
>
> >
> >I think I explained it in previous mails, and if not - sorry, but
> >I clearly can't explain good enough - the point is that with the way how
> >extensions now work, t
On 01/30/2012 09:23 AM, hubert depesz lubaczewski wrote:
I think I explained it in previous mails, and if not - sorry, but
I clearly can't explain good enough - the point is that with the way how
extensions now work, they are useless for providing way to create
tables that will store data, in c
On Mon, Jan 30, 2012 at 11:30:51AM -0500, Tom Lane wrote:
> That is way too vague for my taste, as you have not shown the pg_dump
> options you're using, for example.
OK.
i tried to explain that the options don't matter, but here we go. full
example:
I have two diferent databases: 9.1.2 and 9.2de
hubert depesz lubaczewski writes:
> On Mon, Jan 30, 2012 at 11:12:09AM -0500, Tom Lane wrote:
>> What tests were those exactly? I'm not aware of any agreed changes in
>> this area.
> 1. create table with extension
> 2. try to dump it's content with pg_dump
> 3. try to dump schema of database
> 4
On Mon, Jan 30, 2012 at 08:20:15AM -0800, Adrian Klaver wrote:
> I am not sure I understand crippled. There is a bug that you acknowledge has
> been dealt with. The rest is documented behavior having to do with extension
> packaging. Extensions exist as packages and are put into the database and
On Mon, Jan 30, 2012 at 11:12:09AM -0500, Tom Lane wrote:
> Yes, that's the intended behavior. The purpose of the
> configuration-table feature is to dump data that is needed for an
> extension to operate properly --- for instance postgis has some
> auxiliary tables that are best treated as part o
On Monday, January 30, 2012 7:39:13 am hubert depesz lubaczewski wrote:
> On Mon, Jan 30, 2012 at 07:34:49AM -0800, Adrian Klaver wrote:
> > Breaks certain cases when using pg_dump -s. Some of what you highlight
> > above is designed behavior. What is happening is covered by my second
> > rule of
hubert depesz lubaczewski writes:
> On Sat, Jan 28, 2012 at 01:10:39PM -0500, Tom Lane wrote:
>> Um, yes. Read the manual.
>> http://www.postgresql.org/docs/9.1/static/extend-extensions.html#AEN51966
> Yes, but:
> If you create table using extensions, and the you insert data to it
> - this data
On Mon, Jan 30, 2012 at 07:34:49AM -0800, Adrian Klaver wrote:
> Breaks certain cases when using pg_dump -s. Some of what you highlight above
> is
> designed behavior. What is happening is covered by my second rule of life
> 'Easy
> is difficult'. In this case it is the desire for a built in '
On Monday, January 30, 2012 5:08:41 am hubert depesz lubaczewski wrote:
> On Sat, Jan 28, 2012 at 01:10:39PM -0500, Tom Lane wrote:
> > hubert depesz lubaczewski writes:
> > > is it by design that tables listed there (in extconfig column of
> > > pg_extension) will be dumped with data, even for pg
On Sat, Jan 28, 2012 at 01:10:39PM -0500, Tom Lane wrote:
> hubert depesz lubaczewski writes:
> > is it by design that tables listed there (in extconfig column of
> > pg_extension) will be dumped with data, even for pg_dump --schema?
>
> Um, yes. Read the manual.
> http://www.postgresql.org/docs
On Saturday, January 28, 2012 1:29:22 am hubert depesz lubaczewski wrote:
> On Fri, Jan 27, 2012 at 03:11:32PM -0800, Adrian Klaver wrote:
> > Not sure that it makes a difference, but on the chance it does, what
> > are the options and are they the same for all machines?
>
> $ pg_config --configur
hubert depesz lubaczewski writes:
> is it by design that tables listed there (in extconfig column of
> pg_extension) will be dumped with data, even for pg_dump --schema?
Um, yes. Read the manual.
http://www.postgresql.org/docs/9.1/static/extend-extensions.html#AEN51966
r
On Fri, Jan 27, 2012 at 08:03:06PM -0500, Tom Lane wrote:
> Do the command lines actually look exactly like that?
Yes. Exactly.
This is ubuntu, and --schema is parsed - more details in mail i sent
a minute ago as reply to Adrians mail.
Best regards,
depesz
--
The best thing about modern socie
On Fri, Jan 27, 2012 at 03:11:32PM -0800, Adrian Klaver wrote:
> Not sure that it makes a difference, but on the chance it does, what
> are the options and are they the same for all machines?
$ pg_config --configure
'--prefix=/opt/pgbrew/9.1.2' '--with-pgport=5910' '--enable-debug'
'--with-perl' '
hubert depesz lubaczewski writes:
> I have weird situation.
> pg 9.1.2, compilet by our own script from source, on 10+ machines.
> on fours machines, pg_dump -s - dumps with data!:
> postgres@machine:~$ pg_dump --verbose --schema-only dbname > q
> ...
> pg_dump: creating TABLE x1
> pg_dump: res
On 01/27/2012 03:05 PM, hubert depesz lubaczewski wrote:
On Fri, Jan 27, 2012 at 03:00:24PM -0800, Adrian Klaver wrote:
On 01/27/2012 02:19 PM, hubert depesz lubaczewski wrote:
hiu
I have weird situation.
pg 9.1.2, compilet by our own script from source, on 10+ machines.
on fours machines, pg_d
On Fri, Jan 27, 2012 at 03:00:24PM -0800, Adrian Klaver wrote:
> On 01/27/2012 02:19 PM, hubert depesz lubaczewski wrote:
> >hiu
> >I have weird situation.
> >pg 9.1.2, compilet by our own script from source, on 10+ machines.
> >on fours machines, pg_dump -s - dumps with data!:
>
> Are those 4 ma
On 01/27/2012 02:19 PM, hubert depesz lubaczewski wrote:
hiu
I have weird situation.
pg 9.1.2, compilet by our own script from source, on 10+ machines.
on fours machines, pg_dump -s - dumps with data!:
Are those 4 machines different from the other 6+?
What does the script do?
I am guessing you
hiu
I have weird situation.
pg 9.1.2, compilet by our own script from source, on 10+ machines.
on fours machines, pg_dump -s - dumps with data!:
postgres@machine:~$ pg_dump --verbose --schema-only dbname > q
...
pg_dump: creating TABLE x1
pg_dump: restoring data for table "x2"
pg_dump: dumping c
31 matches
Mail list logo
