On May 11, 2015, at 5:01 PM, Tom Lane t...@sss.pgh.pa.us 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
David E. Wheeler da...@justatheory.com writes:
On May 5, 2015, at 9:40 AM, Tom Lane t...@sss.pgh.pa.us 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
Tom,
On May 5, 2015, at 9:40 AM, Tom Lane t...@sss.pgh.pa.us 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
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_proc
David G. Johnston david.g.johns...@gmail.com writes:
On Thu, May 7, 2015 at 4:19 PM, Tom Lane t...@sss.pgh.pa.us 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.
Bruce Momjian br...@momjian.us 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
On Thu, May 7, 2015 at 4:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us 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
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 an
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
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
On May 5, 2015, at 10:07 AM, Alvaro Herrera alvhe...@2ndquadrant.com 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
Alvaro Herrera alvhe...@2ndquadrant.com 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,
David G. Johnston david.g.johns...@gmail.com writes:
On Tue, May 5, 2015 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com 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
On Tue, May 5, 2015 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com 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
14 matches
Mail list logo
