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