Re: Schema version management

From: Christopher Browne <cbbrowne(at)gmail(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Schema version management
Date: 2012-07-05 22:03:26
Message-ID: CAFNqd5UgbzNd_dbMOpRc1mV539jPpuma=g4G2FVFW=Wa_9=wXQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 5, 2012 at 5:52 PM, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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 experience, the overloaded functions
>> people seem to have in their databases are like do_stuff_to_foobars()
>> and you have one version for foos and another one for bars.
>
> +1
>
> I too want to have my overloaded functions all in the same file, as much
> as to have made that the only behavior in getddl.py:

That seems pretty appropriate to me.

The converse makes my head hurt...

If I have a bunch of overloaded functions, whose definitions *aren't*
really related, are we competing for the "obfuscated PostgreSQL"
contest?

In practice, that sounds like something I'd want to add to my list of
"fire people that do this!" Bad Practices.

>> If you're doing lots of equality functions, surely it would make more
>> sense to package them up as an extension anyway along with all the other
>> thingies you need for the type you're supposedly writing. So it's a
>> completely different market than what we're aiming at here.
>
> +1
+1

> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
>> function's argument list into a filename. However, we're being
>> short-sighted to only think of functions here. What about operators?
>> Or casts? Those don't have simple names either.
>
> 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.

Indeed. Is this something we ought to document as a recommendation?
It's not exactly reference material, but if it's a good practice,
perhaps it should be in the manuals somewhere...
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2012-07-05 22:44:11 Re: foreign key locks
Previous Message Jan Urbański 2012-07-05 21:54:26 Re: Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings to Python encodings.