Tom Lane | 11 Jun 15:50 2013
Picon

Re: Completely broken replica after PANIC: WAL contains references to invalid pages

Sergey Konoplev <gray.ru <at> gmail.com> writes:
> Just curious, what is the planned date for the next minor release, and
> BTW where is it possible to see the roadmap for minor releases?

There is no planned date, and certainly no "roadmap".  We make minor
releases when the core team judges that enough (or severe enough)
fixes have accumulated since the last time.  Historically we've averaged
about four minor releases a year, but that's not set in stone anywhere.

			regards, tom lane

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Tom Lane | 10 Jun 20:45 2013
Picon

Re: bug in Prepared statement with DELETE RETURNING and rule on view

[ got around to looking at this thread finally ]

Amit Kapila <amit.kapila <at> huawei.com> writes:
> What happens when you change ON DELETE rule of the view that really deletes
> elements is that command type after applying rule remains same which means
> Delete, so it can set the Tag.

The point here is that in extended-query mode, we've defined that only
the same statement that sets the command tag can return RETURNING rows.
In the case at hand, the original DELETE isn't executed at all, being
replaced by an UPDATE according to the rule.  But we don't change the
returned command tag to UPDATE, and we don't let the UPDATE's RETURNING
clause return anything to the client.  Both of these rules are meant to
ensure unsurprising behavior as seen from the client side.  We could
debate changing them, but I'd be pretty worried about breaking user
applications if we did.

At the same time, things don't look terribly consistent because in psql
(which uses simple query protocol) you *do* see the RETURNING results.
That's because simple query protocol doesn't have a restriction that
only one resultset can be returned from a single query.  So it's a lot
more wild-west as to what will really happen, and application code is
expected to just deal with that.  psql doesn't have a problem with
multiple query results because it doesn't particularly care what they
are; it's just going to print each one.  Apps that are supposed to
actually make sense of the data have more of an issue with that.  The
extended query protocol was explicitly designed to lock things down
better so that interactions would be more predictable.

The main thing I'm noticing in looking at this is that the documentation
(Continue reading)

Gunnlaugur Thor Briem | 10 Jun 15:28 2013
Picon

pg_dump is O(N) in DB table count N even if dumping only one table

Hi,

pg_dump takes O(N) time dumping just one table (or a few) explicitly specified with a -t parameter. It thus becomes painfully slow on a database with very many tables.

(The use case is copying a few tables over to a test DB, from a large production data warehouse.)

The three queries taking O(N) time are listed below. AFAICT each of these queries could be filtered by table name/OID, at least when the number of tables matching the -t parameters is small, allowing pg_dump to complete in seconds rather than minutes.

SELECT c.tableoid, c.oid, c.relname, c.relacl, c.relkind, c.relnamespace, (SELECT rolname FROM pg_catalog.pg_roles WHERE oid = c.relowner) AS rolname, c.relchecks, c.relhastriggers, c.relhasindex, c.relhasrules, c.relhasoids, c.relfrozenxid, tc.oid AS toid, tc.relfrozenxid AS tfrozenxid, c.relpersistence, CASE WHEN c.reloftype <> 0 THEN c.reloftype::pg_catalog.regtype ELSE NULL END AS reloftype, d.refobjid AS owning_tab, d.refobjsubid AS owning_col, (SELECT spcname FROM pg_tablespace t WHERE t.oid = c.reltablespace) AS reltablespace, array_to_string(c.reloptions, ', ') AS reloptions, array_to_string(array(SELECT 'toast.' || x FROM unnest(tc.reloptions) x), ', ') AS toast_reloptions FROM pg_class c LEFT JOIN pg_depend d ON (c.relkind = 'S' AND d.classid = c.tableoid AND d.objid = c.oid AND d.objsubid = 0 AND
d.refclassid = c.tableoid AND d.deptype = 'a') LEFT JOIN pg_class tc ON (c.reltoastrelid = tc.oid) WHERE c.relkind in ('r', 'S', 'v', 'c', 'f') ORDER BY c.oid

SELECT tableoid, oid, typname, typnamespace, '{=U}' AS typacl, (SELECT rolname FROM pg_catalog.pg_roles WHERE oid = typowner) AS rolname, typinput::oid AS typinput, typoutput::oid AS typoutput, typelem, typrelid, CASE WHEN typrelid = 0 THEN ' '::"char" ELSE (SELECT relkind FROM pg_class WHERE oid = typrelid) END AS typrelkind, typtype, typisdefined, typname[0] = '_' AND typelem != 0 AND (SELECT typarray FROM pg_type te WHERE oid = pg_type.typelem) = oid AS isarray FROM pg_type

SELECT classid, objid, refclassid, refobjid, deptype FROM pg_depend WHERE deptype != 'p' AND deptype != 'e' ORDER BY 1,2

Cheers,

Gulli

matt7416 | 9 Jun 20:30 2013
Picon

BUG #8219: Windows installer fails when username contains spaces

The following bug has been logged on the website:

Bug reference:      8219
Logged by:          Matthew King
Email address:      matt7416 <at> gmail.com
PostgreSQL version: 9.2.4
Operating system:   Windows 7 (64-bit)
Description:        

I attempted to install PostgreSQL 9.2.4, but the installer failed with
"Invalid %COMSPEC%". I checked the installer log. It appears the reason for
failure was that my username ("Matt (2)") contains spaces.

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

daniel.zlatev | 9 Jun 17:12 2013
Picon

BUG #8218: Error when querying an JSON data, 9.3beta

The following bug has been logged on the website:

Bug reference:      8218
Logged by:          Daniel Zlatev
Email address:      daniel.zlatev <at> gmail.com
PostgreSQL version: Unsupported/Unknown
Operating system:   Windows
Description:        

Dears,

today I was playing with some JSON data, and I have noticed something
strange.

1. I've created the follwing table:
CREATE TABLE products (
    data JSON
);

2. Then inserting some data:
INSERT INTO products(data) VALUES('{"id": 1, "name": "shoes", "in_stock":
5}');
INSERT INTO products(data) VALUES('[1,2,3,4,5]');

3. Then i've run this SELECT statement
SELECT * FROM products WHERE (data->>'in_stock')::integer > 0

Output was:
[Err] ERROR: cannot extract field from a non-object

I can understand the reason behind this error(JSON array don't has fields),
but for me it is very logical postgres to exclude this row from the
returning set, rather to throw an error.

So that is it.

Best regards
Daniel

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

sunitha.mudumba | 7 Jun 04:50 2013
Picon

BUG #8216: TO_DATE does not support th format provided

The following bug has been logged on the website:

Bug reference:      8216
Logged by:          Sunitha Mudumba
Email address:      sunitha.mudumba <at> blss.com.au
PostgreSQL version: 9.2.4
Operating system:   Windows
Description:        

To_date does not throw an error when an invalid date is provided to it
select to_date('10-30-2012','dd-MM-YYYY');

It is not forcing the format on the date,  instead it stores 2014-06-14.

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Rafał Rzepecki | 6 Jun 16:24 2013
Picon

Re: BUG #8198: ROW() literals not supported in an IN clause

On Wed, Jun 5, 2013 at 7:58 AM, Amit Kapila <amit.kapila <at> huawei.com> wrote:
> On Wednesday, June 05, 2013 5:34 AM Rafał Rzepecki wrote:
>> On Tue, Jun 4, 2013 at 12:35 PM, Amit Kapila <amit.kapila <at> huawei.com>
>> wrote:
>> > On Saturday, June 01, 2013 9:37 PM
>> >
>> >> Row type literals constructed with ROW() cause an error when used in
>> >> an IN clause (string literals casted appropriately are allowed).
>> This
>> >> is especially problematic since many client libraries use these
>> >> literals to pass values of row-type arguments, hence making it
>> >> impossible to use them in IN-clause queries.
>> >>
>>
>> If I'm right, the proper fix would be (patch 0001; caution, not
>> tested):
>>
>> --- a/src/backend/parser/parse_expr.c
>> +++ b/src/backend/parser/parse_expr.c
>>  <at>  <at>  -1203,10 +1203,9  <at>  <at>  transformAExprIn(ParseState *pstate, A_Expr *a)
>>                 Node       *rexpr = (Node *) lfirst(l);
>>                 Node       *cmp;
>>
>> -               if (haveRowExpr)
>> +               if (haveRowExpr && IsA(lexpr, RowExpr))
>>                 {
>> -                       if (!IsA(lexpr, RowExpr) ||
>> -                               !IsA(rexpr, RowExpr))
>> +                       if (!IsA(rexpr, RowExpr))
>>                                 ereport(ERROR,
>>
>> (errcode(ERRCODE_SYNTAX_ERROR),
>>                                    errmsg("arguments of row IN must all
>> be row expressions"),
>>
>>
>> Since the restriction seems a rather arbitrary (at least I fail to see
>> any reason for it), it can be removed altogether (patch 0002, not
>> tested as well):
>>
>> --- a/src/backend/parser/parse_expr.c
>> +++ b/src/backend/parser/parse_expr.c
>>  <at>  <at>  -1203,20 +1203,12  <at>  <at>  transformAExprIn(ParseState *pstate, A_Expr *a)
>>                 Node       *rexpr = (Node *) lfirst(l);
>>                 Node       *cmp;
>>
>> -               if (haveRowExpr)
>> -               {
>> -                       if (!IsA(lexpr, RowExpr) ||
>> -                               !IsA(rexpr, RowExpr))
>> -                               ereport(ERROR,
>> -
>> (errcode(ERRCODE_SYNTAX_ERROR),
>> -                                  errmsg("arguments of row IN must
>> all be row expressions"),
>> -
>> parser_errposition(pstate, a->location)));
>> +               if (IsA(lexpr, RowExpr) && IsA(rexpr, RowExpr))
>>                         cmp = make_row_comparison_op(pstate,
>>
>>           a->name,
>>                                                           (List *)
>> copyObject(((RowExpr *) lexpr)->args),
>>
>>           ((RowExpr *) rexpr)->args,
>>
>>           a->location);
>> -               }
>>                 else
>>                         cmp = (Node *) make_op(pstate,
>>                                                                    a-
>> >name,
>>
>
> I had tried, both your patches have passed all regression tests (tested on Windows). I feel fixing it in a
way similar to your Patch-1 would be
> more appropriate as with Patch-1 it can generate meaningful error message for some cases like below:
>
> postgres=# select * from the_table where ROW('abc','def') in (row('foo','bar')::the_row,12);
> ERROR:  arguments of row IN must all be row expressions
> LINE 1: select * from the_table where ROW('abc','def') in (row('foo'...

Perhaps you're right, rare cases when you want to do something like
'ROW('abc','def') in (row('foo','bar')::the_row, a_column)' are, I
suppose, so exotic that working around this restriction probably won't
be much of a hassle.
--
Rafał Rzepecki

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

ijmorlan | 6 Jun 18:00 2013
Picon
Picon

BUG #8215: pg_dump includes table out of order in SQL dump

The following bug has been logged on the website:

Bug reference:      8215
Logged by:          Isaac Morland
Email address:      ijmorlan <at> uwaterloo.ca
PostgreSQL version: 9.2.4
Operating system:   Server: Ubuntu 12.04; Client: Mac OS X 10.5.8
Description:        

My understanding is that pg_dump is supposed to include tables in SQL dumps
in alphabetical order by table name.  If this is wrong then this bug may be
invalid and I apologize.

In a dump of a particular schema, I'm getting a particular table always
coming first.  Renaming it to other names does not affect its placement in
the output.  By contrast, renaming other tables does change their location
in the resulting output.

I've tried a few things to try to figure out what might be different about
the problem table with no success so far.

This is a schema-only dump (--schema-only).

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

m+psql | 6 Jun 03:22 2013

BUG #8214: SIGSEGV in PyEval_EvalFrameEx

The following bug has been logged on the website:

Bug reference:      8214
Logged by:          Miron Cuperman
Email address:      m+psql <at> tradehill.com
PostgreSQL version: 9.2.4
Operating system:   Debian 6.0 (squeeze)
Description:        

This is an intermittent crash during a ~5 minute unit test run.

My intuition is that raising an uncaught exception in python tends to
trigger this, but I could be wrong.

Packages:

ii  pgdg-keyring                        2012.1                       keyring
for apt.postgresql.org
ii  postgresql-9.2                      9.2.4-1.pgdg60+1            
object-relational SQL database, version 9.2 server
ii  postgresql-9.2-dbg                  9.2.4-1.pgdg60+1             debug
symbols for postgresql-9.2
ii  postgresql-client-9.2               9.2.4-1.pgdg60+1            
front-end programs for PostgreSQL 9.2
ii  postgresql-client-common            141.pgdg60+1                 manager
for multiple PostgreSQL client versions
ii  postgresql-common                   141.pgdg60+1                
PostgreSQL database-cluster manager
ii  postgresql-contrib                  9.2+141.pgdg60+1            
additional facilities for PostgreSQL (supported version)
ii  postgresql-contrib-9.2              9.2.4-1.pgdg60+1            
additional facilities for PostgreSQL
ii  postgresql-plpython3-9.2            9.2.4-1.pgdg60+1            
PL/Python 3 procedural language for PostgreSQL 9.2

Stack trace from core:

#0  0x00007f012b5b1997 in ?? () from /usr/lib/libpython3.1.so.1.0
#1  0x00007f012b615045 in PyEval_EvalFrameEx () from
/usr/lib/libpython3.1.so.1.0
#2  0x00007f012b5a6068 in ?? () from /usr/lib/libpython3.1.so.1.0
#3  0x00007f012b5824ab in PyIter_Next () from /usr/lib/libpython3.1.so.1.0
#4  0x00007f012ba53ab7 in PLy_exec_function (fcinfo=<optimized out>,
proc=<optimized out>)
    at
/tmp/buildd/postgresql-9.2-9.2.4/build-py3/../src/pl/plpython/plpy_exec.c:108
#5  0x00007f012ba544c4 in plpython3_call_handler (fcinfo=<optimized out>)
    at
/tmp/buildd/postgresql-9.2-9.2.4/build-py3/../src/pl/plpython/plpy_main.c:236
#6  0x00007f01389e98b7 in ExecMakeFunctionResult (fcache=0x7f013ac5f9a0,
econtext=<optimized out>, 
    isNull=0x7f013ac603f8 "p\345K:\001\177", isDone=0x7f013ac60510)
    at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/executor/execQual.c:1794
#7  0x00007f01389e4c6e in ExecTargetList (isDone=<optimized out>,
itemIsDone=<optimized out>, 
    isnull=<optimized out>, values=<optimized out>, econtext=<optimized
out>, targetlist=<optimized out>)
    at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/executor/execQual.c:5221
#8  ExecProject (projInfo=<optimized out>, isDone=<optimized out>)
    at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/executor/execQual.c:5436
#9  0x00007f01389fce7b in ExecResult (node=0x7f013ac5f6a0)
    at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/executor/nodeResult.c:155
#10 0x00007f01389e4218 in ExecProcNode (node=0x7f013ac5f6a0)
    at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/executor/execProcnode.c:372
#11 0x00007f01389e300a in ExecutePlan (dest=<optimized out>,
direction=<optimized out>, 
    numberTuples=<optimized out>, sendTuples=<optimized out>,
operation=<optimized out>, 
    planstate=<optimized out>, estate=<optimized out>)
    at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/executor/execMain.c:1395
#12 standard_ExecutorRun (queryDesc=0x7f013acc5660, direction=731641472,
count=0)
    at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/executor/execMain.c:303
#13 0x00007f0138ac2837 in PortalRunSelect (portal=0x7f013a4f5920,
forward=<optimized out>, count=0, 
    dest=0x7f013a581a78) at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/tcop/pquery.c:944
#14 0x00007f0138ac3c80 in PortalRun (portal=<optimized out>,
count=<optimized out>, 
    isTopLevel=<optimized out>, dest=<optimized out>, altdest=<optimized
out>, 
    completionTag=<optimized out>)
    at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/tcop/pquery.c:788
#15 0x00007f0138abfe0d in exec_simple_query (query_string=<optimized out>)
    at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/tcop/postgres.c:1046
---Type <return> to continue, or q <return> to quit---
#16 0x00007f0138ac0e00 in PostgresMain (argc=<optimized out>,
argv=<optimized out>, 
    dbname=0x7f013a4bf6a8 "app_test", username=<optimized out>)
    at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/tcop/postgres.c:3959
#17 0x00007f0138a79cf3 in BackendRun (port=<optimized out>)
    at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/postmaster/postmaster.c:3614
#18 BackendStartup (port=<optimized out>)
    at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/postmaster/postmaster.c:3304
#19 ServerLoop () at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/postmaster/postmaster.c:1367
#20 0x00007f0138a7cc8c in PostmasterMain (argc=<optimized out>,
argv=0x7f013a4be190)
    at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/postmaster/postmaster.c:1127
#21 0x00007f0138a1838b in main (argc=5, argv=0x7f013a4be170)
    at
/tmp/buildd/postgresql-9.2-9.2.4/build/../src/backend/main/main.c:199

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

eric-postgresql | 5 Jun 19:45 2013
Picon

BUG #8213: Set-valued function error in union

The following bug has been logged on the website:

Bug reference:      8213
Logged by:          Eric Soroos
Email address:      eric-postgresql <at> soroos.net
PostgreSQL version: 9.0.13
Operating system:   Ubuntu 10.04, 32bit
Description:        

This has been replicated on 9.2.4 and HEAD by ilmari_ and johto.

erics <at> dev:~/trunk/sql$ psql -a -h 192.168.10.249 -f pg_bug_report.sql
\set VERBOSITY verbose
\set echo all
select version();
                                                  version                   

------------------------------------------------------------------------------------------------------------
 PostgreSQL 9.0.13 on i686-pc-linux-gnu, compiled by GCC gcc-4.4.real
(Ubuntu 4.4.3-4ubuntu5) 4.4.3, 32-bit
(1 row)

-- this fails. I'd expect it to succeed. 
select id, dt from
   (select 1 as id, generate_series(now()::date, now()::date + '1
month'::interval, '1 day')::date as dt
	union
    select 2, now()::date
) as foo
where dt < now()+'15 days'::interval;
psql:pg_bug_report.sql:13: ERROR:  0A000: set-valued function called in
context that cannot accept a set
LOCATION:  ExecMakeFunctionResult, execQual.c:1733
-- this succeeds, but returns a timestamp
select id, dt from
   (select 1 as id, generate_series(now()::date, now()::date + '1
month'::interval, '1 day') as dt
	union
    select 2, now()::date
) as foo
where dt < now()+'15 days'::interval;
 id |         dt          
----+---------------------
  1 | 2013-06-05 00:00:00
  1 | 2013-06-06 00:00:00
  1 | 2013-06-07 00:00:00
  1 | 2013-06-08 00:00:00
  1 | 2013-06-09 00:00:00
  1 | 2013-06-10 00:00:00
  1 | 2013-06-11 00:00:00
  1 | 2013-06-12 00:00:00
  1 | 2013-06-13 00:00:00
  1 | 2013-06-14 00:00:00
  1 | 2013-06-15 00:00:00
  1 | 2013-06-16 00:00:00
  1 | 2013-06-17 00:00:00
  1 | 2013-06-18 00:00:00
  1 | 2013-06-19 00:00:00
  1 | 2013-06-20 00:00:00
  2 | 2013-06-05 00:00:00
(17 rows)

--this also succeeds, without the where clause
select id, dt from
   (select 1 as id, generate_series(now()::date, now()::date + '1
month'::interval, '1 day')::date as dt
	union
    select 2, now()::date
) as foo;
 id |     dt     
----+------------
  1 | 2013-06-05
  1 | 2013-06-06
  1 | 2013-06-07
  1 | 2013-06-08
  1 | 2013-06-09
  1 | 2013-06-10
  1 | 2013-06-11
  1 | 2013-06-12
  1 | 2013-06-13
  1 | 2013-06-14
  1 | 2013-06-15
  1 | 2013-06-16
  1 | 2013-06-17
  1 | 2013-06-18
  1 | 2013-06-19
  1 | 2013-06-20
  1 | 2013-06-21
  1 | 2013-06-22
  1 | 2013-06-23
  1 | 2013-06-24
  1 | 2013-06-25
  1 | 2013-06-26
  1 | 2013-06-27
  1 | 2013-06-28
  1 | 2013-06-29
  1 | 2013-06-30
  1 | 2013-07-01
  1 | 2013-07-02
  1 | 2013-07-03
  1 | 2013-07-04
  1 | 2013-07-05
  2 | 2013-06-05
(32 rows)

--this also succeeds, without the union
select id, dt from
   (select 1 as id, generate_series(now()::date, now()::date + '1
month'::interval, '1 day')::date as dt
) as foo
where dt < now()+'15 days'::interval;
 id |     dt     
----+------------
  1 | 2013-06-05
  1 | 2013-06-06
  1 | 2013-06-07
  1 | 2013-06-08
  1 | 2013-06-09
  1 | 2013-06-10
  1 | 2013-06-11
  1 | 2013-06-12
  1 | 2013-06-13
  1 | 2013-06-14
  1 | 2013-06-15
  1 | 2013-06-16
  1 | 2013-06-17
  1 | 2013-06-18
  1 | 2013-06-19
  1 | 2013-06-20
(16 rows)

-- this is the workaround.
select id, dt from
   (select 1 as id, generate_series(now()::date, now()::date + '1
month'::interval, '1 day')::date as dt
	union all
    select 2, now()::date
) as foo
where dt < now()+'15 days'::interval;
 id |     dt     
----+------------
  1 | 2013-06-05
  1 | 2013-06-06
  1 | 2013-06-07
  1 | 2013-06-08
  1 | 2013-06-09
  1 | 2013-06-10
  1 | 2013-06-11
  1 | 2013-06-12
  1 | 2013-06-13
  1 | 2013-06-14
  1 | 2013-06-15
  1 | 2013-06-16
  1 | 2013-06-17
  1 | 2013-06-18
  1 | 2013-06-19
  1 | 2013-06-20
  2 | 2013-06-05
(17 rows)

-- this is another workaround:
begin; 
BEGIN
create temp view gs as
   select 1 as id, generate_series(now()::date, now()::date + '1
month'::interval, '1 day') as dt;
CREATE VIEW
create temp view container as
   select id, dt::date from gs
   union
   select 2, now()::date;
CREATE VIEW
select * from container where dt < now()+'15 days'::interval; 
 id |     dt     
----+------------
  1 | 2013-06-05
  1 | 2013-06-06
  1 | 2013-06-07
  1 | 2013-06-08
  1 | 2013-06-09
  1 | 2013-06-10
  1 | 2013-06-11
  1 | 2013-06-12
  1 | 2013-06-13
  1 | 2013-06-14
  1 | 2013-06-15
  1 | 2013-06-16
  1 | 2013-06-17
  1 | 2013-06-18
  1 | 2013-06-19
  1 | 2013-06-20
  2 | 2013-06-05
(17 rows)

rollback;
ROLLBACK
-- another workaround
select id, dt from
   (select 1 as id, generate_series(now()::date, now()::date + '1
month'::interval, '1 day')::date as dt
	union
    select 2, now()::date offset 0
) as foo
where dt < now()+'15 days'::interval;
 id |     dt     
----+------------
  1 | 2013-06-05
  1 | 2013-06-06
  1 | 2013-06-07
  1 | 2013-06-08
  1 | 2013-06-09
  1 | 2013-06-10
  1 | 2013-06-11
  1 | 2013-06-12
  1 | 2013-06-13
  1 | 2013-06-14
  1 | 2013-06-15
  1 | 2013-06-16
  1 | 2013-06-17
  1 | 2013-06-18
  1 | 2013-06-19
  1 | 2013-06-20
  2 | 2013-06-05
(17 rows)

erics <at> dev:~/trunk/sql$ 

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

geoff.montee | 5 Jun 18:07 2013
Picon

BUG #8212: Feature request: View original value of current_user in function with SECURITY DEFINER set

The following bug has been logged on the website:

Bug reference:      8212
Logged by:          Geoff Montee
Email address:      geoff.montee <at> gmail.com
PostgreSQL version: 9.2.4
Operating system:   Linux
Description:        

When a user calls a function that has SECURITY DEFINER set, the value of
"current_user" is changed to the name of the role that defined the
function.

For some use cases, it would be useful to be able to obtain the original
value of "current_user" from within the function. Specifically, this would
make sense in trigger functions used for auditing, where recording only
session_user may not be sufficient.

--

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Gmane