Re: 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, etc.

On Tue, Jun 26, 2012 at 6:04 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> I don't think either of these problems ought to be a complete
> show-stopper. It seems to me that the trade-off is that when object
> names are long, contain special characters, or are overloaded, we'll
> have to munge the names in some way to prevent collisions. That could
> mean that the names are not 100% stable, which would possibly produce
> some annoyance if you're using a VCS to track changes, but maybe
> that's an acceptable trade-off, because it shouldn't happen very
> often. If we could guararantee that identifiers less than 64
> characters which are not overloaded and contain no special characters
> requiring quoting end up in an eponymous file, I think that would be
> good enough to make most of our users pretty happy. In other cases, I
> think the point would just be to make it work (with a funny name)
> rather than fail.
>

I agree. It's not a problem if the filename is not identical to the name of
the object, as long as the same name generates the same filename on
all architectures. Url escaping would work, but converting all non-ascii
characters to ascii would be nicer, and dropping any problematic characters,
or replacing them with "_" or any other suitable character.

For the small fraction of users how have managed to find a good reason
to name a function "this/is\a/good.name/of/a\function.." the filename
of such a function would be "this_is_a_good_name_of_a_function".

As long as the objects are dumped in the same order, there will be no
merge problems when two developers commit changes of the same
file. I think pg_dump does a reasonable job already making sure the order is
always the same. How big is the problem, really?

It would of course be a little easier to keep track of changes and do
merging
if all overloaded functions would be kept in separate files, but I see that
as a
minor feature request. As long as all objects with the same name are kept in
separate files, that's good enough for my needs, and I have _a lot_ of
functions,
whereof quite a few are overloaded.

>
> > \i /home/postgres/database/gluepay-split/aml/FUNCTION/get_linkid.sql
> > \i /home/postgres/database/gluepay-split/aml/FUNCTION/set_address.sql
>
> It would be better to use \ir here rather than hard-code path names, I
> think. Then you'd only need to require that all the files be in the
> same directory, rather than requiring them to be at a certain
> hard-coded place in the filesystem.
>

I fully agree!
I didn't know about the \ir feature.

Best regards,

Joel Jacobson