On May 11, 2015, at 5:01 PM, Tom Lane wrote:
> Me too. Something fell through the cracks rather badly there :-(.
> Would you check your commit history to see if anything else got missed?
Let’s see…
In
https://github.com/theory/citext/commit/4030b4e1ad9fd9f994a6cdca1126a903682acae4
I copied y
"David E. Wheeler" writes:
> On May 5, 2015, at 9:40 AM, Tom Lane wrote:
>> In
>> http://www.postgresql.org/message-id/bn1pr04mb37467aa1d412223b3d4a595df...@bn1pr04mb374.namprd04.prod.outlook.com
>> it's revealed that the citext extension misdeclares its versions of
>> regexp_matches(): they shou
Tom,
On May 5, 2015, at 9:40 AM, Tom Lane wrote:
> In
> http://www.postgresql.org/message-id/bn1pr04mb37467aa1d412223b3d4a595df...@bn1pr04mb374.namprd04.prod.outlook.com
> it's revealed that the citext extension misdeclares its versions of
> regexp_matches(): they should return SETOF text[] but
"David G. Johnston" writes:
> On Thu, May 7, 2015 at 4:19 PM, Tom Lane wrote:
>> pg_upgrade is okay in any case because it dumps and reloads the current
>> extension's components. Doesn't matter whether there's another version
>> that is not compatible.
> âFor clarity - which one is "current"
On Thu, May 7, 2015 at 4:19 PM, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, May 7, 2015 at 04:19:52PM -0400, Bruce Momjian wrote:
> >> Just a reality check but this will break a pg_upgrade, and will not be
> >> detected by --check.
>
> > Actually, pg_upgrade might be OK because the view
Bruce Momjian writes:
> On Thu, May 7, 2015 at 04:19:52PM -0400, Bruce Momjian wrote:
>> Just a reality check but this will break a pg_upgrade, and will not be
>> detected by --check.
> Actually, pg_upgrade might be OK because the views would be recreated
> with the new functions already install
On Thu, May 7, 2015 at 04:19:52PM -0400, Bruce Momjian wrote:
> On Tue, May 5, 2015 at 02:07:08PM -0300, Alvaro Herrera wrote:
> > Tom Lane wrote:
> >
> > > * We can't use CREATE OR REPLACE FUNCTION in the upgrade script because
> > > that intentionally doesn't let you change the result type of
On Tue, May 5, 2015 at 02:07:08PM -0300, Alvaro Herrera wrote:
> Tom Lane wrote:
>
> > * We can't use CREATE OR REPLACE FUNCTION in the upgrade script because
> > that intentionally doesn't let you change the result type of an existing
> > function. I considered doing a manual UPDATE of the pg_p
"David G. Johnston" writes:
> On Tue, May 5, 2015 at 10:20 AM, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> I think we should keep the 1.0 version this time, in back branches.
>> Agreed. Maybe we shouldn't even make 1.1 the default in the back
>> branches.
> âDoes 9.0 get different treatme
On Tue, May 5, 2015 at 10:20 AM, Tom Lane wrote:
> Alvaro Herrera writes:
> > (I think it is possible that the behavior change is actually problematic
> > as opposed to just behaving differently. For instance, if the function
> > is used in a subselect that's expected to return only one row, an
Alvaro Herrera writes:
> (I think it is possible that the behavior change is actually problematic
> as opposed to just behaving differently. For instance, if the function
> is used in a subselect that's expected to return only one row, and it
> suddenly starts returning more, the query would rais
On May 5, 2015, at 10:07 AM, Alvaro Herrera wrote:
>> So AFAICS we need to actually drop and recreate
>> the citext regexp_matches() functions in the upgrade script. That means
>> "ALTER EXTENSION citext UPDATE" will fail if these functions are being
>> used in any views. That's annoying but I
Tom Lane wrote:
> * We can't use CREATE OR REPLACE FUNCTION in the upgrade script because
> that intentionally doesn't let you change the result type of an existing
> function. I considered doing a manual UPDATE of the pg_proc entry, but
> then remembered why CREATE OR REPLACE FUNCTION is picky a
In
http://www.postgresql.org/message-id/bn1pr04mb37467aa1d412223b3d4a595df...@bn1pr04mb374.namprd04.prod.outlook.com
it's revealed that the citext extension misdeclares its versions of
regexp_matches(): they should return SETOF text[] but they're marked
as returning just text[].
We know generally
14 matches
Mail list logo
