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