On Fri, Jul 13, 2012 at 9:41 PM, Peter Eisentraut pete...@gmx.net wrote:
Personally, I hate this proposed nested directory structure. I would
like to have all objects in one directory.
But there is a lot of personally in this thread, of course.
Why do you hate it?
It's a bit like saying,
On lör, 2012-07-14 at 10:41 +0200, Joel Jacobson wrote:
On Fri, Jul 13, 2012 at 9:41 PM, Peter Eisentraut pete...@gmx.net wrote:
Personally, I hate this proposed nested directory structure. I would
like to have all objects in one directory.
But there is a lot of personally in this
On Sat, Jul 14, 2012 at 11:25 AM, Peter Eisentraut pete...@gmx.net wrote:
Well, of course everyone uses directories in moderation. But you might
want to take a look at the gcc source code. You'll love it. ;-)
Yes, but GCC was also created by someone who picks stuff from his bare
foot and eats
On Sat, Jul 14, 2012 at 12:34 PM, Joel Jacobson j...@trustly.com wrote:
On Sat, Jul 14, 2012 at 11:25 AM, Peter Eisentraut pete...@gmx.net wrote:
Well, of course everyone uses directories in moderation. But you might
want to take a look at the gcc source code. You'll love it. ;-)
On ons, 2012-07-11 at 17:20 -0400, Alvaro Herrera wrote:
operator_!___numeric.sql (postfix, name does not need escape)
operator_%7C%2F_integer__.sql (prefix)
operator_%3C_bit_varying__bit_varying.sql (type name with spaces,
changed to _)
I'm not sure if it makes things better to escape some
On tor, 2012-07-12 at 16:14 +0200, Joel Jacobson wrote:
Could work. But I think it's more relevant and useful to keep all objects
in a schema in its own directory.
Personally, I hate this proposed nested directory structure. I would
like to have all objects in one directory.
But there is a
On Wed, Jul 11, 2012 at 8:01 PM, Merlin Moncure mmonc...@gmail.com wrote:
After extensive off-list discussion with Joel it became clear that
per-object dumping ability really belongs in pg_restore.
The only benefit I could see in putting it in pg_restore is you would then
be able to do a
On Wed, Jul 11, 2012 at 11:20 PM, Alvaro Herrera alvhe...@commandprompt.com
wrote:
operator_!___numeric.sql (postfix, name does not need escape)
operator_%7C%2F_integer__.sql (prefix)
operator_%3C_bit_varying__bit_varying.sql (type name with spaces,
changed to _)
I think the directory
Joel Jacobson j...@trustly.com writes:
I think the directory structure [schema]/[type]/[name] should be the same
for all object types. I don't like operator being part of the filename,
it should be the directory name.
What are you going to do with objects that don't have schemas?
(Including,
On Thursday, July 12, 2012, Tom Lane wrote:
What are you going to do with objects that don't have schemas?
(Including, but not restricted to, the schemas themselves.)
Good question. Maybe something like this?
For objects without schema:
/global/[type]/[name].sql
For objects with schema:
Joel Jacobson j...@trustly.com writes:
On Thursday, July 12, 2012, Tom Lane wrote:
What are you going to do with objects that don't have schemas?
(Including, but not restricted to, the schemas themselves.)
Good question. Maybe something like this?
For objects without schema:
On Thu, Jul 12, 2012 at 4:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, I think you could save a level of naming if you were willing to
put the type first, since the type would imply whether the object
lives in a schema or not:
[type]/[name].sql
[type]/[schema]/[name].sql
On 07/12/2012 10:01 AM, Tom Lane wrote:
FWIW, I think you could save a level of naming if you were willing to
put the type first, since the type would imply whether the object
lives in a schema or not:
[type]/[name].sql
[type]/[schema]/[name].sql
On Wed, Jul 11, 2012 at 12:24 AM, Merlin Moncure mmonc...@gmail.com wrote:
What does your patch do that you can't already do with pg_restore?
Please read through the entire thread, think question has already been
answered.
On Tue, Jul 10, 2012 at 5:24 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Sun, May 20, 2012 at 2:41 PM, Joel Jacobson j...@trustly.com wrote:
Hi,
I just read a very interesting post about schema version management.
Quote: You could set it up so that every developer gets their own
test
On tis, 2012-07-10 at 17:54 -0400, Andrew Dunstan wrote:
In general, NTFS forbids the use of these printable ASCII chars in
filenames (see
http://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations:
* : ? \ / |
Many of these could be used in operators.
Yeah, that's a
Excerpts from Peter Eisentraut's message of mié jul 11 17:03:03 -0400 2012:
On tis, 2012-07-10 at 17:54 -0400, Andrew Dunstan wrote:
In general, NTFS forbids the use of these printable ASCII chars in
filenames (see
On sön, 2012-07-08 at 18:52 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On lör, 2012-07-07 at 17:18 -0400, Tom Lane wrote:
Sure. You need not look further than / to find an operator name
that
absolutely *will* cause trouble if it's dumped into a filename
literally.
On 07/10/2012 05:39 PM, Peter Eisentraut wrote:
On sön, 2012-07-08 at 18:52 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On lör, 2012-07-07 at 17:18 -0400, Tom Lane wrote:
Sure. You need not look further than / to find an operator name
that
absolutely *will* cause
On Tue, Jul 10, 2012 at 11:39 PM, Peter Eisentraut pete...@gmx.net wrote:
On sön, 2012-07-08 at 18:52 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On lör, 2012-07-07 at 17:18 -0400, Tom Lane wrote:
Sure. You need not look further than / to find an operator name
that
On Sun, May 20, 2012 at 2:41 PM, Joel Jacobson j...@trustly.com wrote:
Hi,
I just read a very interesting post about schema version management.
Quote: You could set it up so that every developer gets their own
test database, sets up the schema there, takes a dump, and checks that
in. There
On Saturday, July 7, 2012, Tom Lane wrote:
If we think that operators outside of extensions will be an infrequent
special case, what about just dumping all of them into a single file
named operators? And similarly for casts?
regards, tom lane
+1
On lör, 2012-07-07 at 11:32 -0400, Aidan Van Dyk wrote:
But, since you're using operators, what would you think is an
appropriate name for the file the operator is dumped into?
The name of the operator, just like for any other object. (Assuming
we're using the name of a table for the file for
On lör, 2012-07-07 at 17:18 -0400, Tom Lane wrote:
Sure. You need not look further than / to find an operator name that
absolutely *will* cause trouble if it's dumped into a filename
literally.
But that problem applies to all object names.
If we think that operators outside of extensions
Peter Eisentraut pete...@gmx.net writes:
On lör, 2012-07-07 at 17:18 -0400, Tom Lane wrote:
Sure. You need not look further than / to find an operator name that
absolutely *will* cause trouble if it's dumped into a filename
literally.
But that problem applies to all object names.
In
On Fri, Jul 6, 2012 at 4:50 PM, Peter Eisentraut pete...@gmx.net wrote:
I have code in the wild that defines new operators and casts and has no
C code and is not in an extension and has no business being in an
extension.
Nobody is claiming that pgdump shouldn't dump it.
But, since you're
Excerpts from Aidan Van Dyk's message of sáb jul 07 11:32:33 -0400 2012:
On Fri, Jul 6, 2012 at 4:50 PM, Peter Eisentraut pete...@gmx.net wrote:
I have code in the wild that defines new operators and casts and has no
C code and is not in an extension and has no business being in an
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Aidan Van Dyk's message of sáb jul 07 11:32:33 -0400 2012:
But, since you're using operators, what would you think is an
appropriate name for the file the operator is dumped into?
I was thinking that it might make sense to group
Tom Lane t...@sss.pgh.pa.us writes:
This argument seems a bit irrelevant to me. pg_dump doesn't get to pick
and choose what will be in the database it's told to dump. If we're
Sure.
going to do something like what Joel wants, we have to have file naming
conventions for operator and cast
On Fri, Jul 6, 2012 at 8:23 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Tom Lane t...@sss.pgh.pa.us writes:
This argument seems a bit irrelevant to me. pg_dump doesn't get to pick
and choose what will be in the database it's told to dump. If we're
Sure.
going to do something like
: [HACKERS] Schema version management
On Fri, Jul 6, 2012 at 8:23 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Tom Lane t...@sss.pgh.pa.us writes:
This argument seems a bit irrelevant to me. pg_dump doesn't get to
pick
and choose what will be in the database it's told to dump
On tor, 2012-07-05 at 23:52 +0200, Dimitri Fontaine wrote:
I would argue like Álvaro that when dealing with operators and casts
you're probably writing an extension already, and we're providing
another way to deal with that.
I have code in the wild that defines new operators and casts and has
On Thu, Jul 5, 2012 at 2:38 AM, Robert Haas robertmh...@gmail.com wrote:
My vote is - when there's an overloaded function, put each version in
its own file. And name the files something like
functionname_something.sql. And just document that something may not
be entirely stable.
I would
On Thu, Jul 5, 2012 at 3:15 AM, Joel Jacobson j...@trustly.com wrote:
On Thu, Jul 5, 2012 at 2:38 AM, Robert Haas robertmh...@gmail.com wrote:
My vote is - when there's an overloaded function, put each version in
its own file. And name the files something like
functionname_something.sql.
On Thu, Jul 5, 2012 at 4:04 AM, Gurjeet Singh singh.gurj...@gmail.comwrote:
On Thu, Jul 5, 2012 at 3:15 AM, Joel Jacobson j...@trustly.com wrote:
On Thu, Jul 5, 2012 at 2:38 AM, Robert Haas robertmh...@gmail.comwrote:
My vote is - when there's an overloaded function, put each version in
its
On Jul 5, 2012, at 9:21, Andrew Dunstan wrote:
No they are not necessarily one logical unit. You could have a bunch of
functions called, say, equal which have pretty much nothing to do with
each other, since they refer to different types.
+1 from me for putting one function definition per
On Thu, Jul 5, 2012 at 3:32 PM, Michael Glaesemann g...@seespotcode.netwrote:
On Jul 5, 2012, at 9:21, Andrew Dunstan wrote:
No they are not necessarily one logical unit. You could have a bunch of
functions called, say, equal which have pretty much nothing to do with
each other, since
Maybe it could be made an option to pg_dump?
Some users and their systems might not even have overloaded functions,
and these users will of course prefer a nice looking filename, i.e. all
functions
having the same name kept in the same file. Which for them will mean only
one function per file
Joel Jacobson j...@trustly.com writes:
Maybe it could be made an option to pg_dump?
Ick. Then we have to deal with all the downsides of *both* methods.
pg_dump is already a bloated, nearly unmaintainable mess. The very
last thing it needs is even more options.
On Thu, Jul 5, 2012 at 4:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Ick. Then we have to deal with all the downsides of *both* methods.
pg_dump is already a bloated, nearly unmaintainable mess. The very
last thing it needs is even more options.
When you say bloated, are you referring to
Excerpts from Tom Lane's message of jue jul 05 10:46:52 -0400 2012:
Joel Jacobson j...@trustly.com writes:
Maybe it could be made an option to pg_dump?
Ick. Then we have to deal with all the downsides of *both* methods.
pg_dump is already a bloated, nearly unmaintainable mess. The very
On Thu, Jul 5, 2012 at 5:17 PM, Alvaro Herrera
alvhe...@commandprompt.comwrote:
Agreed.
However I am also against what seems to be the flow. Normally, you
don't write overloaded plpgsql functions such as equal. Case in
point, the equality functions in core have funny names like int4eq and
On Jul 5, 2012, at 11:17, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of jue jul 05 10:46:52 -0400 2012:
Joel Jacobson j...@trustly.com writes:
Maybe it could be made an option to pg_dump?
Ick. Then we have to deal with all the downsides of *both* methods.
pg_dump is
Excerpts from Michael Glaesemann's message of jue jul 05 11:36:51 -0400 2012:
On Jul 5, 2012, at 11:17, Alvaro Herrera wrote:
However I am also against what seems to be the flow. Normally, you
don't write overloaded plpgsql functions such as equal.
I often write functions that perform
On Jul 5, 2012, at 11:52, Alvaro Herrera wrote:
Isn't this a perfect example of stuff that, since it does much the same
thing, should be in the same file so that you remember to fix them all
together if you find a bug in one?
That's what tests are for.
Michael Glaesemann
grzm seespotcode
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Michael Glaesemann's message of jue jul 05 11:36:51 -0400 2012:
If we're dumping objects (tables, views, functions, what-have-you) into
separate files,
each of these functions is a separate object and should be in its own file.
On Thu, Jul 5, 2012 at 5:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
FWIW, I'm attracted to the all-similarly-named-functions-together
method, mainly because it dodges the problem of how to encode a
function's argument list into a filename. However, we're being
short-sighted to only think of
Joel Jacobson j...@trustly.com writes:
On Thu, Jul 5, 2012 at 4:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
pg_dump is already a bloated, nearly unmaintainable mess. The very
last thing it needs is even more options.
If you are referring to the code, I don't think that's a good argument
On Thu, Jul 5, 2012 at 11:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Michael Glaesemann's message of jue jul 05 11:36:51 -0400 2012:
If we're dumping objects (tables, views, functions, what-have-you) into
separate files,
each of
On Thu, Jul 5, 2012 at 6:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, to be perfectly frank, I already doubt that this entire feature
passes the complexity-versus-value test, because pg_dump is not a
substitute for an SCM --- people who have got enough functions to need
this sort of thing
Excerpts from Christopher Browne's message of jue jul 05 12:10:09 -0400 2012:
I wound up expanding the function arguments and using function + args
as the name. That leads to a risk of rather long names for functions,
but there aren't many other ways possible.
Well, maybe not many, but you
On Jul 5, 2012, at 3:21 PM, Andrew Dunstan wrote:
No they are not necessarily one logical unit. You could have a bunch of
functions called, say, equal which have pretty much nothing to do with
each other, since they refer to different types.
+1 from me for putting one function definition
On Thu, Jul 5, 2012 at 12:57 PM, David E. Wheeler da...@justatheory.com wrote:
On Jul 5, 2012, at 3:21 PM, Andrew Dunstan wrote:
No they are not necessarily one logical unit. You could have a bunch of
functions called, say, equal which have pretty much nothing to do with
each other, since
I'd rather have the few overloaded-functions in one file (hopefully
with deterministic ordering) and a sane, simple filename, than have
every function in every database in a separate file with some strange
mess in the filename that makes me cringe every time I see it.
Having tried it both
Alvaro Herrera alvhe...@commandprompt.com writes:
However I am also against what seems to be the flow. Normally, you
don't write overloaded plpgsql functions such as equal. Case in
point, the equality functions in core have funny names like int4eq and
so on. Instead, at least in my
On Thu, Jul 5, 2012 at 5:52 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
However I am also against what seems to be the flow. Normally, you
don't write overloaded plpgsql functions such as equal. Case in
point, the equality functions in
Christopher Browne cbbro...@gmail.com writes:
On Thu, Jul 5, 2012 at 5:52 PM, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
Tom Lane t...@sss.pgh.pa.us writes:
FWIW, I'm attracted to the all-similarly-named-functions-together
method, mainly because it dodges the problem of how to encode a
On Wed, Jul 4, 2012 at 9:02 AM, Joel Jacobson j...@trustly.com wrote:
On Tue, Jul 3, 2012 at 7:49 PM, Peter Eisentraut pete...@gmx.net wrote:
I think this idea has merit. Prepare a patch and put it into the next
commit fest.
Glad to hear, I'm on it!
I see the problem that since the dump
On Tue, Jul 3, 2012 at 7:49 PM, Peter Eisentraut pete...@gmx.net wrote:
I think this idea has merit. Prepare a patch and put it into the next
commit fest.
Glad to hear, I'm on it!
I see the problem that since the dump order is in general not
deterministic, this will cause random
On ons, 2012-06-27 at 10:02 +0200, Joel Jacobson wrote:
Robert, thank you for keeping this thread alive.
Hopefully some more will join the discussion.
I'm still hopeful the community can manage to agree upon acceptable
tradeoffs and work-arounds to make this possible.
I think this idea has
Robert, thank you for keeping this thread alive.
Hopefully some more will join the discussion.
I'm still hopeful the community can manage to agree upon acceptable
tradeoffs and work-arounds to make this possible.
I think the benefits clearly outweighs the minor issues of filenames,
dumping
On Tue, May 22, 2012 at 11:31 PM, Joel Jacobson j...@trustly.com wrote:
This is true, which means some users won't be able to use the feature,
because they are using an ancient OS or have function names with slashes,
hm, is it even possible to have function names with slashes?
Sure. If you
Joel Jacobson wrote:
hm, is it even possible to have function names with slashes?
test=# create function is/it\even
possible?() returns void language plpgsql as $$begin end;$$;
CREATE FUNCTION
test=# select is/it\even
possible?();
is/it\even+
possible?
--
(1 row)
-Kevin
On Mon, May 21, 2012 at 5:25 PM, Joel Jacobson j...@trustly.com wrote:
If one want to reuse the splitting to files-code of the directory
format, maybe the existing option -F d could be tweaked to output in
both a a machine-readable format (current way), and also a
human-friendly tree of files
On Wed, May 23, 2012 at 3:24 AM, Daniel Farina dan...@heroku.com wrote:
Is there a reason why the current directory format could not be
adjusted to become more human-readable friendly for mechanical
reasons? I realize there is a backwards compatibility problem, but it
may be better than
Joel Jacobson j...@trustly.com writes:
If the entire function identity arguments would be included in the filename,
two dumps of the same schema in two different databases
would be guaranteed to produce the same dump.
This would render some very long filenames for functions with many
On Wed, May 23, 2012 at 9:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Thus, not implausibly, causing the dump to fail entirely on some
filesystems. Case sensitivity, encoding issues, and special characters
in names (eg slashes or backslashes, depending on platform) are
additional pain points.
On the topic on fixing pg_dump to dump in a predictable order, can
someone please update me on the current state of the problem?
I've read though pg_dump_sort.c, and note objects are first sorted in
type/name-based ordering, then topologically sorted in a way which
minimize unnecessary
On Mon, May 21, 2012 at 5:03 AM, Joel Jacobson j...@trustly.com wrote:
http://archives.postgresql.org/pgsql-hackers/2010-12/msg02301.php
The initial feedback was on the usage of OIDs as file names.
This was indeed a bad idea and was changed, see
On Sun, May 20, 2012 at 9:03 PM, Joel Jacobson j...@trustly.com wrote:
On Mon, May 21, 2012 at 10:06 AM, Daniel Farina dan...@heroku.com wrote:
Also, now that I look more carefully, there was a lot of conversation
about this patch; it seems like what you are doing now is reporting
its
On Tue, May 22, 2012 at 3:30 AM, Daniel Farina dan...@heroku.com wrote:
Thank you, that's very informative. I'd like to reiterate one
question, though, which is something like:
How do you feel that the since-committed directory-output/input
support in pg_dump/pg_restore could or should
On 05/21/2012 08:25 PM, Joel Jacobson wrote:
On Tue, May 22, 2012 at 3:30 AM, Daniel Farinadan...@heroku.com wrote:
Thank you, that's very informative. I'd like to reiterate one
question, though, which is something like:
How do you feel that the since-committed directory-output/input
Hi,
I just read a very interesting post about schema version management.
Quote: You could set it up so that every developer gets their own
test database, sets up the schema there, takes a dump, and checks that
in. There are going to be problems with that, including that dumps
produced by pg_dump
On Sun, May 20, 2012 at 12:41 PM, Joel Jacobson j...@trustly.com wrote:
Hi,
I just read a very interesting post about schema version management.
Quote: You could set it up so that every developer gets their own
test database, sets up the schema there, takes a dump, and checks that
in. There
On Mon, May 21, 2012 at 8:08 AM, Daniel Farina dan...@heroku.com wrote:
I think you are absolutely right, but I'm not sure if teaching pg_dump
a new option is the best idea. It's a pretty complex program as-is.
I've also heard some people who really wish pg knew how to self-dump
for valid
On Sun, May 20, 2012 at 7:36 PM, Joel Jacobson j...@trustly.com wrote:
On Mon, May 21, 2012 at 8:08 AM, Daniel Farina dan...@heroku.com wrote:
I think you are absolutely right, but I'm not sure if teaching pg_dump
a new option is the best idea. It's a pretty complex program as-is.
I've also
On Mon, May 21, 2012 at 10:06 AM, Daniel Farina dan...@heroku.com wrote:
Also, now that I look more carefully, there was a lot of conversation
about this patch; it seems like what you are doing now is reporting
its successful use, and I did not understand that by reading the
abstract of your
77 matches
Mail list logo
