Re: [HACKERS] Schema version management

On Sat, Jul 14, 2012 at 12:34 PM, Joel Jacobson wrote: > On Sat, Jul 14, 2012 at 11:25 AM, Peter Eisentraut 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. ;-) [505][joel.Joel-Jacobsons-iMac-2: /Use

Re: [HACKERS] Schema version management

On Sat, Jul 14, 2012 at 11:25 AM, Peter Eisentraut 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 it. ;-) --

Re: [HACKERS] Schema version management

On lör, 2012-07-14 at 10:41 +0200, Joel Jacobson wrote: > On Fri, Jul 13, 2012 at 9:41 PM, Peter Eisentraut 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,

Re: [HACKERS] Schema version management

On Fri, Jul 13, 2012 at 9:41 PM, Peter Eisentraut 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, - I hate

Re: [HACKERS] Schema version management

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 l

Re: [HACKERS] Schema version management

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 som

Re: [HACKERS] Schema version management

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 T

Re: [HACKERS] Schema version management

On Thu, Jul 12, 2012 at 4:01 PM, 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 > > Could wor

Re: [HACKERS] Schema version management

Joel Jacobson 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: > /global/[type]/[name].s

Re: [HACKERS] Schema version management

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:

Re: [HACKERS] Schema version management

Joel Jacobson 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, but not restr

Re: [HACKERS] Schema version management

On Wed, Jul 11, 2012 at 11:20 PM, 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 think the directory structure [schema]/[type]/

Re: [HACKERS] Schema version management

On Wed, Jul 11, 2012 at 8:01 PM, Merlin Moncure 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 --split on already e

Re: [HACKERS] Schema version management

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 > >

Re: [HACKERS] Schema version management

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 > : > > " * : < > ? \ / | > Many of these could be used in operators. Yeah, t

Re: [HACKERS] Schema version management

On Tue, Jul 10, 2012 at 5:24 PM, Merlin Moncure wrote: > On Sun, May 20, 2012 at 2:41 PM, Joel Jacobson 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

Re: [HACKERS] Schema version management

On Wed, Jul 11, 2012 at 12:24 AM, Merlin Moncure 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.

Re: [HACKERS] Schema version management

On Sun, May 20, 2012 at 2:41 PM, Joel Jacobson 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 are goi

Re: [HACKERS] Schema version management

On Tue, Jul 10, 2012 at 11:39 PM, Peter Eisentraut wrote: > On sön, 2012-07-08 at 18:52 -0400, Tom Lane wrote: >> Peter Eisentraut 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 *wil

Re: [HACKERS] Schema version management

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 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 dum

Re: [HACKERS] Schema version management

On sön, 2012-07-08 at 18:52 -0400, Tom Lane wrote: > Peter Eisentraut 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. >

Re: [HACKERS] Schema version management

Peter Eisentraut 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 principle,

Re: [HACKERS] Schema version management

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 extensio

Re: [HACKERS] Schema version management

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

Re: [HACKERS] Schema version management

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

Re: [HACKERS] Schema version management

Alvaro Herrera 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 operators according

Re: [HACKERS] Schema version management

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 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.

Re: [HACKERS] Schema version management

On Fri, Jul 6, 2012 at 4:50 PM, Peter Eisentraut 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 using operators,

Re: [HACKERS] Schema version management

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 ha

Re: [HACKERS] Schema version management

ristopher Browne; Pg Hackers > Subject: Re: [HACKERS] Schema version management > > On Fri, Jul 6, 2012 at 8:23 AM, Dimitri Fontaine > wrote: > > Tom Lane writes: > >> This argument seems a bit irrelevant to me. pg_dump doesn't get to > pick > >> and choos

Re: [HACKERS] Schema version management

On Fri, Jul 6, 2012 at 8:23 AM, Dimitri Fontaine wrote: > Tom Lane 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

Re: [HACKERS] Schema version management

Tom Lane 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 objects. So we c

Re: [HACKERS] Schema version management

Christopher Browne writes: > On Thu, Jul 5, 2012 at 5:52 PM, Dimitri Fontaine > wrote: >> Tom Lane writes: >>> 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. How

Re: [HACKERS] Schema version management

On Thu, Jul 5, 2012 at 5:52 PM, Dimitri Fontaine wrote: > Alvaro Herrera 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

Re: [HACKERS] Schema version management

Alvaro Herrera 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 experience, the overloaded

Re: [HACKERS] Schema version management

> 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

Re: [HACKERS] Schema version management

On Thu, Jul 5, 2012 at 12:57 PM, David E. Wheeler 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 they refer to d

Re: [HACKERS] Schema version management

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 definit

Re: [HACKERS] Schema version management

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 yo

Re: [HACKERS] Schema version management

On Thu, Jul 5, 2012 at 6:09 PM, Tom Lane 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 need to be keep

Re: [HACKERS] Schema version management

On Thu, Jul 5, 2012 at 11:59 AM, Tom Lane wrote: > Alvaro Herrera 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 obj

Re: [HACKERS] Schema version management

Joel Jacobson writes: > On Thu, Jul 5, 2012 at 4:46 PM, Tom Lane 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 > against implementing new good fea

Re: [HACKERS] Schema version management

On Thu, Jul 5, 2012 at 5:59 PM, Tom Lane 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 functions here.

Re: [HACKERS] Schema version management

Alvaro Herrera 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. > Clearly there is n

Re: [HACKERS] Schema version management

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

Re: [HACKERS] Schema version management

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 tha

Re: [HACKERS] Schema version management

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 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

Re: [HACKERS] Schema version management

On Thu, Jul 5, 2012 at 5:17 PM, Alvaro Herrera wrote: > 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 > so on. Instead,

Re: [HACKERS] Schema version management

Excerpts from Tom Lane's message of jue jul 05 10:46:52 -0400 2012: > Joel Jacobson 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 th

Re: [HACKERS] Schema version management

On Thu, Jul 5, 2012 at 4:46 PM, Tom Lane 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 the code or the c

Re: [HACKERS] Schema version management

Joel Jacobson 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. regards, tom lane --

Re: [HACKERS] Schema version management

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 anyw

Re: [HACKERS] Schema version management

On Thu, Jul 5, 2012 at 3:32 PM, Michael Glaesemann wrote: > > 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 t

Re: [HACKERS] Schema version management

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 definitio

Re: [HACKERS] Schema version management

On Thu, Jul 5, 2012 at 4:04 AM, Gurjeet Singh wrote: > On Thu, Jul 5, 2012 at 3:15 AM, Joel Jacobson wrote: > >> On Thu, Jul 5, 2012 at 2:38 AM, Robert Haas wrote: >> >>> My vote is - when there's an overloaded function, put each version in >>> its own file. And name the files something like >>>

Re: [HACKERS] Schema version management

On Thu, Jul 5, 2012 at 3:15 AM, Joel Jacobson wrote: > On Thu, Jul 5, 2012 at 2:38 AM, Robert Haas 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 somethin

Re: [HACKERS] Schema version management

On Thu, Jul 5, 2012 at 2:38 AM, Robert Haas 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 agree that's better

Re: [HACKERS] Schema version management

On Wed, Jul 4, 2012 at 9:02 AM, Joel Jacobson wrote: > On Tue, Jul 3, 2012 at 7:49 PM, Peter Eisentraut 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 genera

Re: [HACKERS] Schema version management

On Tue, Jul 3, 2012 at 7:49 PM, Peter Eisentraut 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 reordering in your m

Re: [HACKERS] Schema version management

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 h

Re: [HACKERS] Schema version management

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 order

Re: [HACKERS] Schema version management

On Tue, May 22, 2012 at 11:31 PM, Joel Jacobson 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 quote the functi

Re: [HACKERS] Schema version management

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

Re: [HACKERS] Schema version management

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 rearrangem

Re: [HACKERS] Schema version management

On Wed, May 23, 2012 at 9:09 AM, Tom Lane 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.  This does not s

Re: [HACKERS] Schema version management

Joel Jacobson 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 arguments, Thus, not

Re: [HACKERS] Schema version management

On Wed, May 23, 2012 at 3:24 AM, Daniel Farina 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 bloating a new opti

Re: [HACKERS] Schema version management

On Mon, May 21, 2012 at 5:25 PM, Joel Jacobson 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 and content (

Re: [HACKERS] Schema version management

On 05/21/2012 08:25 PM, Joel Jacobson wrote: On Tue, May 22, 2012 at 3:30 AM, Daniel Farina 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_

Re: [HACKERS] Schema version management

On Tue, May 22, 2012 at 3:30 AM, Daniel Farina 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 influence your pa

Re: [HACKERS] Schema version management

On Sun, May 20, 2012 at 9:03 PM, Joel Jacobson wrote: > On Mon, May 21, 2012 at 10:06 AM, Daniel Farina 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 under

Re: [HACKERS] Schema version management

On Mon, May 21, 2012 at 5:03 AM, Joel Jacobson 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 > http://archives.postgresql.org/pgsql-hackers/2010-12/msg023

Re: [HACKERS] Schema version management

On Mon, May 21, 2012 at 10:06 AM, Daniel Farina 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 email.  And, be

Re: [HACKERS] Schema version management

On Sun, May 20, 2012 at 7:36 PM, Joel Jacobson wrote: > On Mon, May 21, 2012 at 8:08 AM, Daniel Farina 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

Re: [HACKERS] Schema version management

On Mon, May 21, 2012 at 8:08 AM, Daniel Farina 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 reasons. Complex

Re: [HACKERS] Schema version management

On Sun, May 20, 2012 at 12:41 PM, Joel Jacobson 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 are go

[HACKERS] Schema version management

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_du