Hi,
today on IRC there was a strange problem shown. The small working example
looks like this:
x=# with x as (insert into a(t) values('1') returning *) select * from x;
t
---
1
(1 row)
x=# with x (insert into a(t) values('1') returning *) select * from x;
ERROR: syntax error at or near "into"
The attached patch adds four new SQL functions for the JSON type:
json_typeof(json) RETURNS text
json_is_object(json) RETURNS boolean
json_is_array(json) RETURNS boolean
json_is_scalar(json) RETURNS boolean
The motivating use-case for this patch is the ability to easily create a
do
Hi Satoshi,
I was wondering about this problem. Please tell us about your system enviroment
which is postgresql version ,OS, raid card, and file system.
Best regards,
--
Mitsumasa KONDO
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On 07/25/2013 02:01 AM, Andres Freund wrote:
> And much of that can trivially/centrally be rewritten to LATERAL, not
> to speak of the cross-version compatibility problem.
An interesting example of that can be found here:
http://stackoverflow.com/q/12414750/398670
where someone's looking for a w
Szymon Guz wrote:
> today on IRC there was a strange problem shown. The small working example
> looks like this:
>
> x=# with x as (insert into a(t) values('1') returning *) select * from x;
> t
> ---
> 1
> (1 row)
>
> x=# with x (insert into a(t) values('1') returning *) select * from x;
> ER
On 07/29/2013 09:56 AM, Craig Ringer wrote:
> Unless LATERAL provides a way to do lock-step iteration through a pair
> (or more) of functions I don't think we can get rid of SRFs-in-FROM just
> yet.
I don't think anyone was arguing for that; we're talking about
deprecating SRFs-in-SELECT.
--
Se
On 07/29/2013 04:31 PM, Vik Fearing wrote:
> On 07/29/2013 09:56 AM, Craig Ringer wrote:
>> Unless LATERAL provides a way to do lock-step iteration through a pair
>> (or more) of functions I don't think we can get rid of SRFs-in-FROM just
>> yet.
>
> I don't think anyone was arguing for that; we'r
Hello
In 9.3 super user can cancel all queries or user can cancel own sessions.
Is possible enhance this possibility to database owners? So owner can
cancel or can terminate sessions related to owned databases?
Regards
Pavel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
On 29 July 2013 11:25, Pavel Stehule wrote:
> Hello
>
> In 9.3 super user can cancel all queries or user can cancel own sessions.
>
> Is possible enhance this possibility to database owners? So owner can
> cancel or can terminate sessions related to owned databases?
>
>
But this means that a db o
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > However, I comment on this mainly because anchovy has had issues with
> > 9.1 and older for some time, which looks like an issue with GCC 4.8.0.
> > Did you happen to resolve or identify what is happening there..?
>
> Yeah, we kno
2013/7/29 Szymon Guz :
> On 29 July 2013 11:25, Pavel Stehule wrote:
>>
>> Hello
>>
>> In 9.3 super user can cancel all queries or user can cancel own sessions.
>>
>> Is possible enhance this possibility to database owners? So owner can
>> cancel or can terminate sessions related to owned database
On 2013-07-29 07:11:13 -0400, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > However, I comment on this mainly because anchovy has had issues with
> > > 9.1 and older for some time, which looks like an issue with GCC 4.8.0.
> > > Did you happen to res
On 29 July 2013 13:20, Pavel Stehule wrote:
> 2013/7/29 Szymon Guz :
> > On 29 July 2013 11:25, Pavel Stehule wrote:
> >>
> >> Hello
> >>
> >> In 9.3 super user can cancel all queries or user can cancel own
> sessions.
> >>
> >> Is possible enhance this possibility to database owners? So owner c
On Sunday, July 28, 2013 11:12 AM Amit kapila wrote:
> On Friday, July 26, 2013 6:18 PM Tom Lane wrote:
> Alvaro Herrera writes:
> >> The main contention point I see is where conf.d lives;
> >> the two options are in $PGDATA or together with postgresql.conf.
> Tom
> >> and Robert, above, say it sh
Andres Freund writes:
> On 2013-07-29 07:11:13 -0400, Stephen Frost wrote:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> The bottom line was:
>>> It looks like our choices are (1) teach configure to enable
>>> -fno-aggressive-loop-optimizations if the compiler recognizes it,
>>> or (2) back-port c
On Mon, Jul 29, 2013 at 8:56 AM, Craig Ringer wrote:
> Unless LATERAL provides a way to do lock-step iteration through a pair
> (or more) of functions I don't think we can get rid of SRFs [in select target
> lists] yet
You don't even need lateral. This works fine:
postgres=# select * from gener
On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-07-29 07:11:13 -0400, Stephen Frost wrote:
> >> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >>> The bottom line was:
> >>> It looks like our choices are (1) teach configure to enable
> >>> -fno-aggressive-loop-optimizat
Andres Freund writes:
> On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
>> If we turn off the optimization, that will fix any other cases as well,
>> no? So why would we risk breaking third-party code by back-porting the
>> struct declaration changes?
> The -fno-agressive-loop thingie afaics only
On 2013-07-29 08:17:46 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
> >> If we turn off the optimization, that will fix any other cases as well,
> >> no? So why would we risk breaking third-party code by back-porting the
> >> struct declaration
Szymon,
* Szymon Guz (mabew...@gmail.com) wrote:
> On 29 July 2013 11:25, Pavel Stehule wrote:
> > In 9.3 super user can cancel all queries or user can cancel own sessions.
> >
> > Is possible enhance this possibility to database owners? So owner can
> > cancel or can terminate sessions related t
Andres Freund writes:
> On 2013-07-29 08:17:46 -0400, Tom Lane wrote:
>> I'm not excited about breaking code in order to fix optimization bugs
>> that are purely hypothetical (and for which there's no particular reason
>> to believe that the proposed change would fix them anyway). If we were
>> s
2013/7/29 Stephen Frost :
> Szymon,
>
> * Szymon Guz (mabew...@gmail.com) wrote:
>> On 29 July 2013 11:25, Pavel Stehule wrote:
>> > In 9.3 super user can cancel all queries or user can cancel own sessions.
>> >
>> > Is possible enhance this possibility to database owners? So owner can
>> > cancel
Le lundi 29 juillet 2013 13:47:57, Amit Kapila a écrit :
> On Sunday, July 28, 2013 11:12 AM Amit kapila wrote:
> > On Friday, July 26, 2013 6:18 PM Tom Lane wrote:
> >
> > Alvaro Herrera writes:
> > >> The main contention point I see is where conf.d lives;
> > >> the two options are in $PGDATA o
On 07/29/2013 01:05 AM, Tom Lane wrote:
Buildfarm member anchovy has been failing for the last couple of days,
evidently because its owner just couldn't wait to adopt bison 3.0,
which is all of 3 days old. The failures look like
Reminder to buildfarm animal owners: if you upgrade software pl
On 2013-07-29 08:44:56 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-07-29 08:17:46 -0400, Tom Lane wrote:
> >> I'm not excited about breaking code in order to fix optimization bugs
> >> that are purely hypothetical (and for which there's no particular reason
> >> to believe that the
Hi,
> On 07/29/2013 01:05 AM, Tom Lane wrote:
>> Buildfarm member anchovy has been failing for the last couple of days,
>> evidently because its owner just couldn't wait to adopt bison 3.0,
>> which is all of 3 days old.
Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily.
On 07/29/2013 08:02 PM, Greg Stark wrote:
>> > Unless LATERAL provides a way to do lock-step iteration through a pair
>> > (or more) of functions I don't think we can get rid of SRFs [in select
>> > target lists] yet
> You don't even need lateral. This works fine:
>
> postgres=# select * from gen
On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
Hi,
On 07/29/2013 01:05 AM, Tom Lane wrote:
Buildfarm member anchovy has been failing for the last couple of days,
evidently because its owner just couldn't wait to adopt bison 3.0,
which is all of 3 days old.
Hmm? Anchovy is upgrading automatica
On 07/29/2013 03:16 AM, Andrew Tipton wrote:
The attached patch adds four new SQL functions for the JSON type:
json_typeof(json) RETURNS text
json_is_object(json) RETURNS boolean
json_is_array(json) RETURNS boolean
json_is_scalar(json) RETURNS boolean
Please add to the next
Andres Freund writes:
> FWIW cherry-picking bf66bfb4cd726b6ddab3fe2718648f65a7106149 and
> e58f3181fdaacc91d4cc1bd98a4a8ad7d286544c fixes the issue for me
> (After fixing trivial conflicts in the latter).
I've already spent more time on this than I wanted to, but just for
the archives' sake: neit
On 2013-07-29 10:46:41 -0400, Andrew Dunstan wrote:
>
> On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
> >Hi,
> >
> >>On 07/29/2013 01:05 AM, Tom Lane wrote:
> >>>Buildfarm member anchovy has been failing for the last couple of days,
> >>>evidently because its owner just couldn't wait to adopt biso
On 2013-07-29 10:52:10 -0400, Tom Lane wrote:
> Andres Freund writes:
> > FWIW cherry-picking bf66bfb4cd726b6ddab3fe2718648f65a7106149 and
> > e58f3181fdaacc91d4cc1bd98a4a8ad7d286544c fixes the issue for me
> > (After fixing trivial conflicts in the latter).
>
> I've already spent more time on th
Andrew Dunstan writes:
> On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
>> Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily.
>> I assumed that's a good thing -- the purpose of build farm is to test
>> PostgreSQL in various different real-life environments? Arch Linux is
>
On Mon, Jul 29, 2013 at 5:53 PM, Andres Freund wrote:
> Both the
> gcc 4.8 and the bison 3.0 problems are things the project needs to know
> about
Perl 5.18 too:
http://www.postgresql.org/message-id/2825.1370226...@sss.pgh.pa.us
Marti
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
> Why not harcode in ParseConfigFp() that we should parse the auto.conf file at
> the end (and/or if USE_AUTO_CONF is not OFF) instead of hacking
> ProcessConfigFile() with data_directory ? (data_directory should be set at
> this
> point) ... just thinking, a very convenient way to enable/dis
On Sun, Jul 28, 2013 at 7:59 AM, MauMau wrote:
> Hello,
>
> I'm sorry I've been touching several things recently before fixing any of
> them.
>
> I've noticed undesirable disk space increase while performing archive
> recovery with PostgreSQL 9.3. This happens with 9.2, too.
>
> I just performed
On Sat, Jul 27, 2013 at 6:57 PM, Tomonari Katsumata
wrote:
> Hi,
>
>
Yes, it prevents PROMOTE_SIGNAL_FILE from remaining even if
both promote files exist.
>>> The command("unlink(PROMOTE_SIGNAL_FILE)") here is for
>>> unusualy case.
>>> Because the case is when done both procedures
On 07/29/2013 11:05 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily.
I assumed that's a good thing -- the purpose of build farm is to test
PostgreSQL in various different real-
On Tue, Jul 23, 2013 at 10:56 PM, Amit Langote wrote:
> On Wed, Jul 24, 2013 at 3:20 AM, Jeff Janes wrote:
>>
>> The heap structure used in external sorts is cache-unfriendly. The
>> bigger the heap used, the more this unfriendliness becomes apparent.
>> And the bigger maintenance_work_mem, the
On Mon, Jul 29, 2013 at 9:15 PM, Andrew Dunstan wrote:
> There has to be something between "set in stone and never changes" and
> "auto-updates everything every 24 hours" that would suit us.
Well sure I could change the update frequency. But again, it seems
like delaying the inevitable.
> I'm to
On 07/29/2013 02:26 PM, Marti Raudsepp wrote:
I'm toying with the idea of a check_upgrade mode for the buildfarm client
where it wouldn't do a git pull, but would report changes if the build
result was different from the previous result. You'd run this immediately
after pulling new changes into
On Mon, Jul 29, 2013 at 4:05 PM, Tom Lane wrote:
> I can see both sides of this. It's definitely nice to get early warning
> when toolchain changes create new problems for Postgres, but it's not
> clear that the buildfarm is the best way to get such notifications.
Perhaps something as simple as
On Mon, Jul 29, 2013 at 11:45 AM, Andrew Dunstan wrote:
>
> On 07/29/2013 02:26 PM, Marti Raudsepp wrote:
>>>
>>> I'm toying with the idea of a check_upgrade mode for the buildfarm client
>>> where it wouldn't do a git pull, but would report changes if the build
>>> result was different from the p
On Sun, Jul 28, 2013 at 7:43 PM, Tom Lane wrote:
> I suspect it's likely to come out about the same either way once you
> account for all the uses of WITH. Might be worth trying both to see
> which seems less ugly.
So I'm not really sure how to do it the other way. Once you're in
parser rules I
All:
Because this patch is still being discussed and tinkered with, I have
moved it to 9.4CF2.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mail
All,
Based on the ongoing discussion of this patch, I have moved it to 9.4CF2
(9-2013).
Mind you, it would be good to commit some version of it before September.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On 18-07-2013 17:02, Alvaro Herrera wrote:
> I think we should just put the config directives of ALTER SYSTEM into a
> file, not dir, alongside postgresql.conf; I would suggest
> postgresql.auto.conf. This file is parsed automatically after
> postgresql.conf, without requiring an "include" directi
On Mon, Jul 29, 2013 at 2:16 AM, Andrew Tipton wrote:
> The attached patch adds four new SQL functions for the JSON type:
> json_typeof(json) RETURNS text
> json_is_object(json) RETURNS boolean
> json_is_array(json) RETURNS boolean
> json_is_scalar(json) RETURNS boolean
>
> The mot
Everyone,
This patch has been marked "ready for committer" since July 2nd. Can
someone please commit it, and let us close out this CF?
Thanks!
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
* Andrew Dunstan wrote:
I'm toying with the idea of a check_upgrade mode for the buildfarm
client where it wouldn't do a git pull, but would report changes if the
build result was different from the previous result. You'd run this
immediately after pulling new changes into your OS. Other, bright
depesz,
moved to -hackers..
* hubert depesz lubaczewski (dep...@depesz.com) wrote:
> create table some_data (id int4 primary key, payload text);
> create view first as select * from some_data where 0 = id % 2 with local
> check option;
> create view second as select * from first where 0 = id wit
On Mon, Jul 29, 2013 at 07:43:53PM -0400, Stephen Frost wrote:
> depesz,
>
> moved to -hackers..
>
> * hubert depesz lubaczewski (dep...@depesz.com) wrote:
> > create table some_data (id int4 primary key, payload text);
> > create view first as select * from some_data where 0 = id % 2 with local
depesz,
* hubert depesz lubaczewski (dep...@depesz.com) wrote:
> On Mon, Jul 29, 2013 at 07:43:53PM -0400, Stephen Frost wrote:
> > * hubert depesz lubaczewski (dep...@depesz.com) wrote:
> > > create table some_data (id int4 primary key, payload text);
> > > create view first as select * from some
Hi Jeff,
On Tue, Jul 30, 2013 at 3:25 AM, Jeff Janes wrote:
> On Tue, Jul 23, 2013 at 10:56 PM, Amit Langote
> wrote:
>> On Wed, Jul 24, 2013 at 3:20 AM, Jeff Janes wrote:
>>>
>>> The heap structure used in external sorts is cache-unfriendly. The
>>> bigger the heap used, the more this unfrie
On Mon, Jul 29, 2013 at 11:05:52AM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
> >> Hmm? Anchovy is upgrading automatically to newest Arch Linux packages
> >> daily.
> >> I assumed that's a good thing -- the purpose of build farm is to test
>
On Tue, Jul 30, 2013 at 3:56 AM, Noah Misch wrote:
> Agreed. Let's stick an "Updates OS packages daily, regularly acquiring
> bleeding-edge upstream releases" note on the buildfarm status page
FWIW, I added "[updated daily]" to the OS version field.
I haven't changed other configuration yet, wi
On Monday, July 29, 2013 7:15 PM Cédric Villemain wrote:
> Le lundi 29 juillet 2013 13:47:57, Amit Kapila a écrit :
> > On Sunday, July 28, 2013 11:12 AM Amit kapila wrote:
> > > On Friday, July 26, 2013 6:18 PM Tom Lane wrote:
> > >
> > > Alvaro Herrera writes:
> > > >> The main contention point
On Mon, Jul 29, 2013 at 12:59:27PM +0930, Tom Dunstan wrote:
> I'm trying to hack a trigger function to evaluate an expression on the
> tuple that the trigger has been fired for, kinda like a check
> constraint. I looked at ExecRelCheck in execMain.c which does
> more-or-less what I want to do, and
On Tuesday, July 30, 2013 1:17 AM Josh Berkus wrote:
On Tuesday, July 30, 2013 1:17 AM Amit kapila wrote:
> All,
>
> Based on the ongoing discussion of this patch, I have moved it to
> 9.4CF2
> (9-2013).
I had already sent the updated patch based on recent suggestions.
I am really not sure if so
59 matches
Mail list logo
