I wrote:
> Sergey Burladyan writes:
>> How about contrib/ ? I have this in my test 8.3.7 database:
> That stuff should all be marked strict ... on the whole I'm not sure
> that contrib is null-safe anyway, independently of this particular
> issue. AFAIK no one's really gone through it.
So I jus
Sergey Burladyan writes:
> How about contrib/ ? I have this in my test 8.3.7 database:
That stuff should all be marked strict ... on the whole I'm not sure
that contrib is null-safe anyway, independently of this particular
issue. AFAIK no one's really gone through it.
re
Tom Lane writes:
> This would be a serious security problem if it weren't for the fact that
> nearly all internal-accepting functions in the backend are also marked
> STRICT, and so they won't get called in this type of scenario. A query
> to pg_proc shows that the only ones that aren't strict a
"Greg Sabino Mullane" writes:
>> Normally we would consider a pg_proc change as requiring a catversion
>> bump. Since we are already past 8.4 beta we couldn't do that without
>> forcing an initdb for beta testers.
> I think a serious issue like this warrants a bump. It seems like you are
> sayin
Gurjeet Singh writes:
> Can we hold it till 8.4.1? Or is that not an option?
What advantage would that have? We certainly wouldn't wish to put a
catversion change into 8.4.1.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On Tue, Jun 9, 2009 at 11:14 PM, Tom Lane wrote:
> Andrew Dunstan writes:
> > Tom Lane wrote:
> >> This will ensure the fix is in place and protecting future coding,
> >> although possibly not getting enforced in 8.4 production instances that
> >> were upgraded from beta (if there are any such).
Andrew Dunstan writes:
> Tom Lane wrote:
>> This will ensure the fix is in place and protecting future coding,
>> although possibly not getting enforced in 8.4 production instances that
>> were upgraded from beta (if there are any such).
> How common is this scenario? It's certainly not something
On Tue, Jun 9, 2009 at 12:41 PM, Greg Sabino Mullane wrote:
>> Normally we would consider a pg_proc change as requiring a catversion
>> bump. Since we are already past 8.4 beta we couldn't do that without
>> forcing an initdb for beta testers.
>
> I think a serious issue like this warrants a bump.
Tom Lane wrote:
Normally we would consider a pg_proc change as requiring a catversion
bump. Since we are already past 8.4 beta we couldn't do that without
forcing an initdb for beta testers. What I'd like to do about this
is change the proisstrict settings in pg_proc.h but not bump catversion
Jaime Casanova writes:
> why not bump it just at the final release.
There aren't going to be any more betas, so it's now or not at all.
I don't think we want to plan a catversion bump between RC and final.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-
On Tue, Jun 9, 2009 at 11:31 AM, Tom Lane wrote:
>
> Normally we would consider a pg_proc change as requiring a catversion
> bump. Since we are already past 8.4 beta we couldn't do that without
> forcing an initdb for beta testers. What I'd like to do about this
> is change the proisstrict settin
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Normally we would consider a pg_proc change as requiring a catversion
> bump. Since we are already past 8.4 beta we couldn't do that without
> forcing an initdb for beta testers.
I think a serious issue like this warrants a bump. It seems li
I noticed the following core-dump situation in CVS HEAD:
regression=# select array_agg_finalfn(null);
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attemp
13 matches
Mail list logo
