Stephen Frost wrote
> *
> kurt@
> (
> kurt@
> ) wrote:
>> Allows SELECT from any column, or the specific columns listed, of the
>> specified table, view, or sequence. Also allows the use of COPY TO. This
>> privilege is also needed to reference existing column values in UPDATE or
>> DELET
Tom Lane-2 wrote
> David Johnston <
> polobo@
> > writes:
>>> Here is a minimal query that demonstrates the problem. In 9.1 it works:
>>>
>>> chris=# select * FROM current_user u join (current_user u cross join
>>> current_user v) x on true;
A much more simple example courtesy of Chris Travers from the original
-general thread that I suggested be moved to -bugs.
> Here is a minimal query that demonstrates the problem. In 9.1 it works:
>
> chris=# select * FROM current_user u join (current_user u cross join
> current_user v) x on tr
Fabien COELHO-3 wrote
> The key issue for me is that table Foo is updated (as shown by the last
> column), but although 'two' was updated to '*' by iteration 1, the last
> iteration still sees the initial 'two' which does not exist anymore.
>
> Am I wrong somewhere? Or is this a subtle bug?
My
Michael Kunzmann wrote
> Hello,
>
> I've noticed the following issue when autostarting PostgreSQL under
> Ubuntu 12.04 64bit by bootup. I'm using PostgreSQL 9.1.
>
> A manual service start works (service postgresql start).
Not sure what you actually think is the bug...especially since PostgreSQL
On Thu, Jun 13, 2013 at 4:02 PM, Tom Lane wrote:
> david.g.johns...@gmail.com writes:
> > The following query results in "SQL Error: ERROR: set-valued function
> called
> > in context that cannot accept a set"
>
> > SELECT *, CASE WHEN id = 2 THEN
> > (regexp_matches(input_string,'^0*([1-9]\d+)$'
bricklen wrote
> expression
>
> An expression based on one or more columns of the table. The expression
> usually must be written with surrounding parentheses, as shown in the
> syntax. However, the parentheses can be omitted if the expression has the
> form of a function call.
So in fact the exa
r d-3 wrote
> Hi,
>
> this is with 9.2.4_PGDG / FC18 / 64bit upgraded from 9.1.8 via
> dump/restore, settings kept for the most part.
>
> Table has 1.5M records, the varchar(100) field in question has a *
> varchar_ops* and a *varchar_pattern_ops* btree index.
>
> 3 Cases:
>
>- "MYFIELD" li
smatiz wrote
> The following bug has been logged on the website:
>
> Bug reference: 7784
> Logged by: Santiago Matiz Vasquez
> Email address:
> smatiz@
> PostgreSQL version: 9.2.2
> Operating system: MAC LION 10.7.4
> Description:
>
>
> CREATE OR REPLACE FUNCTION
> -Original Message-
> From: pgsql-bugs-ow...@postgresql.org [mailto:pgsql-bugs-
> ow...@postgresql.org] On Behalf Of w...@devauld.ca
> Sent: Tuesday, November 20, 2012 10:28 AM
> To: pgsql-bugs@postgresql.org
> Subject: [BUGS] BUG #7685: last_value() not consistent throughout window
> part
On Nov 18, 2012, at 2:24, Tom Lane wrote:
> "Greg Sabino Mullane" writes:
>>> If it's a postgres bug, what is the fix? Make the identifier max size
>>> longer?
>
>> I'd also be in favor of this, in addition to upgrading from a NOTICE.
>
> On the whole I'm not too excited about changing this.
>
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Tuesday, July 26, 2011 7:42 PM
To: David Johnston
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #6131: Query Returning Incorrect Results
"David Johnston" writes:
> The embedded script exhibits
The following bug has been logged online:
Bug reference: 6131
Logged by: David Johnston
Email address: pol...@yahoo.com
PostgreSQL version: 9.0.4
Operating system: Windows 7 64-bit
Description:Query Returning Incorrect Results
Details:
The embedded script exhibits
13 matches
Mail list logo
