The following bug has been logged on the website:
Bug reference: 6612
Logged by: Ari Entlich
Email address: atrig...@ccs.neu.edu
PostgreSQL version: 9.1.2
Operating system: Windows?
Description:
Seeing as Postgres does not allow sub-queries in CHECK constraints yet, i
I have 2 databases for single user .
Both these databases connect to 2 different applications.
Configuration for one database is set to maximum 30 connections.
Other database is not configured for maximum allowed connections explicitly.
Now, I receive a broken pipe error for the application with
On Wed, Apr 25, 2012 at 10:33:10AM +, atrig...@ccs.neu.edu wrote:
> Seeing as Postgres does not allow sub-queries in CHECK constraints yet, it
> doesn't make any sense to me for it to allow function calls, since functions
> can perform queries. Additionally, if a function is called from a check
On Wed, Apr 25, 2012 at 11:33 AM, wrote:
> Seeing as Postgres does not allow sub-queries in CHECK constraints yet, it
> doesn't make any sense to me for it to allow function calls, since functions
> can perform queries.
This is why functions must be marked as one of VOLATILE, STABLE, or
IMMUTABL
Greg Stark wrote:
> Only IMMUTABLE functions can be used in CHECK constraints.
> It's a feature that expressions including subqueries are
> automatically detected as not being immutable and automatically
> barred.
It doesn't look like that to me:
test=# create function xxx() returns text vol
snehal maniyar wrote:
> I have 2 databases for single user .
> Both these databases connect to 2 different applications.
>
> Configuration for one database is set to maximum 30 connections.
> Other database is not configured for maximum allowed connections
> explicitly.
>
> Now, I receive a brok
"Kevin Grittner" writes:
> Greg Stark wrote:
>> Only IMMUTABLE functions can be used in CHECK constraints.
> It doesn't look like that to me:
No, we have never enforced that. IIRC the idea has been discussed,
but we thought that adding the restriction would break too many
existing application
On Wed, Apr 25, 2012 at 4:06 PM, Kevin Grittner
wrote:
> A CHECK constraint using a volatile function is potentially valid
> and useful, IMO. Think about a column which is supposed to record
> the moment of an event which has occurred. It could make sense to
> ensure that the timestamptz value i
Greg Stark writes:
> On Wed, Apr 25, 2012 at 4:06 PM, Kevin Grittner
> wrote:
>> A CHECK constraint using a volatile function is potentially valid
>> and useful, IMO.
> Hm. I suppose it depends on what you think a constraint is. I had
> always thought it was a guarantee that all the data in the
Peter Eisentraut writes:
> On tor, 2012-04-19 at 15:00 -0400, Tom Lane wrote:
>> i+pgb...@avdd.tk writes:
>>> A concurrent psql session will overwrite the history of the first. This
>>> does not look good: a database tool causing me to lose my data!
>> Works okay for me. I suspect you need to t
eshkin...@gmail.com writes:
> set timezone to 'W-SU'; select '2011-03-27 23:00:00'::timestamptz;
> SET
> timestamptz
>
> 2011-03-28 02:59:54+04
I've applied a patch for this. Thanks for the report!
regards, tom lane
--
Sent via pg
duncan.bu...@orionvm.com.au writes:
> I found that running a SELECT FOR UPDATE query in a CTE does not block
> simultaneous transactions from running the same query.
The reason this test case doesn't do anything:
> CREATE FUNCTION lock_0(int) returns int as $$
> WITH locked as (
> SEL
Wow, so I guess I'm pretty much wrong about this... Sorry for the noise guys. I
failed to consider different uses for functions, obviously, and it's not
possible to automatically detect usages which could cause problems.
Perhaps this is more of a bug in the documentation than anything else. I
c
The following bug has been logged on the website:
Bug reference: 6613
Logged by: Camil Ghircoias
Email address: ghircoiasca...@yahoo.com
PostgreSQL version: 9.1.3
Operating system: Windows 7
Description:
Had this scenario:
OS:Windows 7
Install postgresql 9.1 in Progr
Ari Entlich writes:
> I do, however, think it should definitely be documented somewhere that
> functions cannot be used to get around the lack of check statement
> subqueries, because the ordering of operations is wrong.
That statement seems to me to be complete nonsense. You can certainly
pu
The following bug has been logged on the website:
Bug reference: 6614
Logged by: Piyush Merja
Email address: piyu...@usindia.com
PostgreSQL version: 9.0.0
Operating system: WindowsXp
Description:
Hello,
I have some table that has name in japanese character when I try
16 matches
Mail list logo
