On Aug 19, 2013, at 9:11 PM, Andres Freund wrote:
> On 2013-08-19 20:15:51 +0200, Boszormenyi Zoltan wrote:
>> 2013-08-19 19:20 keltezéssel, Andres Freund írta:
>>> Hi,
>>>
>>> On 2013-07-24 09:20:52 +0200, Antonin Houska wrote:
Hello,
the purpose of this patch is to limit impact of pg
On Wed, Aug 21, 2013 at 7:29 AM, Bruce Momjian wrote:
> On Tue, Aug 20, 2013 at 08:38:52AM +0530, Amit Kapila wrote:
>> On Tue, Aug 20, 2013 at 8:27 AM, Stephen Frost wrote:
>> > * Amit Kapila (amit.kapil...@gmail.com) wrote:
>> >> If both are okay, then I would like to go with second option (inc
On Tue, Aug 20, 2013 at 10:02 PM, Alvaro Herrera
wrote:
> Stephen Frost escribió:
>> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>> > Well, all the relative paths in include/includedir directives would be
>> > relative to the directory specified by the -c config_file param, which
>> > makes
On Wed, Aug 21, 2013 at 2:54 AM, Tom Lane wrote:
>
> What I'm wondering is whether to back-patch this or leave well enough
> alone. The risk of back-patching is that it might destabilize plan
> choices that people like. (In Tomas' original example, the underestimate
> of the table size leads it
On Tue, Aug 20, 2013 at 08:38:52AM +0530, Amit Kapila wrote:
> On Tue, Aug 20, 2013 at 8:27 AM, Stephen Frost wrote:
> > * Amit Kapila (amit.kapil...@gmail.com) wrote:
> >> If both are okay, then I would like to go with second option (include
> >> file mechanism).
> >> I think by default, we shoul
On Mon, Aug 19, 2013 at 09:27:57PM -0400, Stephen Frost wrote:
> * Andres Freund (and...@2ndquadrant.com) wrote:
> > I vote for adapting the patch to additionally zero out the file via
> > write(). In your tests that seemed to perform at least as good as the
> > old method... It also has the advant
Tom Lane wrote:
> Andres Freund writes:
> > On 2013-08-19 14:28:28 -0400, Tom Lane wrote:
> >> One possibility is to do the initial check somewhere shortly after
> >> ChangeToDataDir(), and have the GUC check hook only attempt to make a
> >> check in SIGHUP context. Unfortunately we aren't passin
In a thread over in pgsql-performance, Tomas Vondra pointed out that
choose_hashed_distinct was sometimes making different choices than
choose_hashed_grouping, so that queries like these:
select distinct x from ... ;
select x from ... group by 1;
might get different plans even tho
On Tue, Aug 20, 2013 at 11:23:06AM -0400, Stephen Frost wrote:
> > What I was proposing upthread is that enable_alter_system=off/on would
> > be present in postgresql.conf, and there is no include line for
> > auto.conf.
>
> I really think that's a terrible approach, to be honest. I want to see
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost escribió:
> > http://www.postgresql.org/docs/9.3/static/runtime-config-file-locations.html
>
> That's talking about the data_directory and the various foo_file
> settings, though; it doesn't apply to the include settings.
Right-
W dniu 20.08.2013 20:55, Boszormenyi Zoltan pisze:
> Here's a new one, for v7:
>
> setrefs.c: In function ‘set_plan_refs’:
> setrefs.c:2001:26: warning: ‘before_index’ may be used uninitialized
> in this function [-Wmaybe-uninitialized]
> bind_returning_variables(rlist, before_index, after_index)
2013-08-20 17:30 keltezéssel, Karol Trzcionka írta:
W dniu 20.08.2013 16:47, Karol Trzcionka pisze:
Thank you for the review and tests. New version introduce a lot of
improvements:
- Fix regression test for view (wrong table_name)
- Add regression test for inheritance
- Delete hack in initsplan.
Stephen Frost escribió:
> And what about
>
> http://www.postgresql.org/docs/9.3/static/runtime-config-file-locations.html
>
> ... ?
>
>"When setting any of these parameters, a relative path will be
>interpreted with respect to the directory in which postgres is
>started."
That's t
Tarvi Pillessaar wrote:
> Maybe someone can take a look at my patch and give some feedback.
> Even if this idea won't reach to upstream, i would still like to get
> feedback.
Please add the patch to the open CommitFest.
You can read about the process here:
http://wiki.postgresql.org/wiki/Com
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost escribió:
> > Of course, the current situation is quite terrible anyway, imv. Having
> > the GUCs be relative to whereever the user happens to run pg_ctl from is
> > pretty ugly- not to mention that the commented out 'defaults' won
On Aug 20, 2013, at 6:50 PM, Tom Lane wrote:
> You need more parentheses -- (source::text) would've worked.
Alas, no, same problem as for CAST():
ERROR: functions in index expression must be marked IMMUTABLE
>> No problem, I can use CAST(), right? So I try:
>>EXCLUDE USING gist (CAS
"David E. Wheeler" writes:
> Well, maybe I can cast it? But no, changing the EXCLUDE line to
> EXCLUDE USING gist (source::text WITH =, within WITH &&)
> Yields a syntax error:
> try.sql:13: ERROR: syntax error at or near "::"
> LINE 4: EXCLUDE USING gist (source::text WITH =,
On Tue, Aug 20, 2013 at 2:55 AM, Gavin Flower
wrote:
> On 20/08/13 15:26, Tom Lane wrote:
>
> I will be taking a long (and long-overdue) vacation from Sep 10 to Oct 20.
> I expect to have email access, but won't be doing much more than minimally
> keeping up with my inbox.
>
> This means I'll be p
Alvaro Herrera writes:
> Stephen Frost escribió:
>> While I really like the 'include auto.conf' style, I'm starting to think
>> it may not be workable after all. Another thing to consider is if the
>> user decides to change that include line.. What happens when the DBA
>> tries to do a 'ALTER SY
Stephen Frost escribió:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > Well, all the relative paths in include/includedir directives would be
> > relative to the directory specified by the -c config_file param, which
> > makes perfect sense. So the conf.d would work fine in your example.
On 08/19/2013 11:55 PM, Gavin Flower wrote:
On 20/08/13 15:26, Tom Lane wrote:
I will be taking a long (and long-overdue) vacation...
but, But, BUT, you're not human - you can't possibly take leave, the
sky will fall & all manners of divers calamities will come to pass!!!
As if on cue:
http:
Hello!
From time to time when investigating different locking issues using
postgres log i have thought that "process x is still waiting for"
message could be more informative, for example at the moment it is quite
painful to find out which session was actually holding that particular lock.
I
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Well, all the relative paths in include/includedir directives would be
> relative to the directory specified by the -c config_file param, which
> makes perfect sense. So the conf.d would work fine in your example.
Why would include/includedir d
On Aug 19, 2013, at 11:28 PM, Heikki Linnakangas wrote:
> On 19.08.2013 23:40, Christophe Pettus wrote:
>> Is it reasonable to note in the documentation that ereport does not return
>> if the error severity is greater than or equal to ERROR?
>
> Yeah, it probably would be good to mention that.
Hackers,
I am trying to do something like this:
CREATE TYPE source AS ENUM(
'fred', 'wilma', 'barney', 'betty'
);
CREATE EXTENSION btree_gist;
CREATE TABLE things (
source source NOT NULL,
within tstzrange NOT NULL,
EXCLUDE USING gist (source WITH
Stephen Frost escribió:
> Tried to in my other mail,
Yep, got it and replied, thanks.
> but let me also point out that we
> ("PGDG"/Upstream) don't "own" the directory in which postgresql.conf
> lives. At least on Debian and relatives, that directory isn't under
> $PGDATA and it already has oth
Stephen Frost escribió:
> I agree that auto.conf should live in $PGDATA, but I really don't like
> the idea of conf.d being relative to some other existing file. It
> should be included through an 'includedir' option, not just picked up as
> some magic directory name, and therefore consider the c
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost escribió:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > > Stephen Frost escribió:
>
> > > > I'd much rather have an includedir directive than some hard-coded or
> > > > command-line option to read the directory.. The
Stephen Frost escribió:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > Stephen Frost escribió:
> > > I'd much rather have an includedir directive than some hard-coded or
> > > command-line option to read the directory.. The directory should live
> > > in /etc/postgresql/X.Y/cluster/ on
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> >> The conf.d/ path would be relative to postgresql.conf, so there's no
> >> need for Debian to patch anything.
>
> > Uhhh, I really don't see that working, at all...
>
> Why n
W dniu 20.08.2013 16:47, Karol Trzcionka pisze:
> Thank you for the review and tests. New version introduce a lot of
> improvements:
> - Fix regression test for view (wrong table_name)
> - Add regression test for inheritance
> - Delete hack in initsplan.c (now we ignore all RTE_BEFORE) - the
> unin
Stephen Frost writes:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>> The conf.d/ path would be relative to postgresql.conf, so there's no
>> need for Debian to patch anything.
> Uhhh, I really don't see that working, at all...
Why not? conf.d is for installable files, AIUI. What we ne
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost escribió:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > > Stephen Frost escribió:
> > > > With includedir and include directives, and postgresql.conf setting a
> > > > defined ordering, with last-wins, you could simply
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> With this design, if you put enable_alter_system=off in auto.conf, there
> is no way for the user to enable alter system again short of editing a
> file in the data directory. I think this is one of the things that was
> "forbidden" by policy; o
Alvaro Herrera writes:
> What I was proposing upthread is that enable_alter_system=off/on would
> be present in postgresql.conf, and there is no include line for
> auto.conf. That way, if the user wishes to enable/disable the feature,
> they need to edit postgresql.conf to do so. ALTER SYSTEM do
Stephen Frost escribió:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > Stephen Frost escribió:
> > > With includedir and include directives, and postgresql.conf setting a
> > > defined ordering, with last-wins, you could simply have the 'includedir'
> > > for conf.d come before the 'inclu
On Tue, Aug 20, 2013 at 11:53 PM, Amit Kapila wrote:
> On Tue, Aug 20, 2013 at 1:11 PM, Sawada Masahiko
> wrote:
>> Hi all,
>>
>> Taking a look at PostgreSQL HEAD today, I noticed that currently
>> PostgreSQL allows "of" value as bool type value.
>> So user can execute the following SQL.
>>
>> =
Stephen Frost escribió:
> * Amit Kapila (amit.kapil...@gmail.com) wrote:
> > So let me try to explain what I understood from above:
> >
> > 1. enable_alter_system a new GUC whose default value =off.
> > 2. Alter System will check this variable and return error (not
> > allowed), if this parameter
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost escribió:
> > With includedir and include directives, and postgresql.conf setting a
> > defined ordering, with last-wins, you could simply have the 'includedir'
> > for conf.d come before the 'include' for auto.conf.
>
> Uh, I was
Stephen Frost escribió:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > Hopefully snippets put in conf.d/ by
> > puppet/chef will override the settings in postgresql.conf (i.e. conf.d/
> > should be processed after postgresql.conf, not before); and hopefully
> > ALTER SYSTEM will in turn
On Tue, Aug 20, 2013 at 1:11 PM, Sawada Masahiko wrote:
> Hi all,
>
> Taking a look at PostgreSQL HEAD today, I noticed that currently
> PostgreSQL allows "of" value as bool type value.
> So user can execute the following SQL.
>
> =# SET enbale_seqscan TO of;
>
> And I read the source code related
Thank you for the review and tests. New version introduce a lot of
improvements:
- Fix regression test for view (wrong table_name)
- Add regression test for inheritance
- Delete hack in initsplan.c (now we ignore all RTE_BEFORE) - the
uninitialized issue
- Revert changing varno in add_vars_to_targe
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> So let me try to explain what I understood from above:
>
> 1. enable_alter_system a new GUC whose default value =off.
> 2. Alter System will check this variable and return error (not
> allowed), if this parameter is off.
> 3. Now if user enables inc
On Tue, Aug 20, 2013 at 7:51 PM, Stephen Frost wrote:
> * Amit Kapila (amit.kapil...@gmail.com) wrote:
>> Wouldn't it be complicated to handle this way rather then by having
>> include directive.
>
> You misunderstood. I was suggesting a setup along these lines:
>
> postgresql.conf:
> # include
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> Wouldn't it be complicated to handle this way rather then by having
> include directive.
You misunderstood. I was suggesting a setup along these lines:
postgresql.conf:
# include = 'auto.conf' # Disabled by default
auto.conf:
###
On Tue, Aug 20, 2013 at 6:55 PM, Stephen Frost wrote:
> * Amit Kapila (amit.kapil...@gmail.com) wrote:
>> On Tue, Aug 20, 2013 at 6:21 PM, Stephen Frost wrote:
>> > I'm not particularly set on this.. Why not create the file initially?
>>If by default this feature needs to be disabled, then i
2013/8/20 David E. Wheeler
> On Aug 20, 2013, at 3:38 PM, Pavel Stehule
> wrote:
>
> > pg_notify returns void, so there are no necessary casting to void
> >
> > so enhanced check - so all returned columns are void should be enough
>
> What if I call another function I wrote myself that returns a
On Aug 20, 2013, at 3:38 PM, Pavel Stehule wrote:
> pg_notify returns void, so there are no necessary casting to void
>
> so enhanced check - so all returned columns are void should be enough
What if I call another function I wrote myself that returns an INT, but I do
not care about the INT? M
On 08/19/2013 11:36 PM, Michael Cronenworth wrote:
On 08/19/2013 07:35 PM, Noah Misch wrote:
That was option #1. (You weren't planning to change just the one symbol
causing the failure at hand, were you?) Reasonable choice. The
point in the
code comment quoted above looks bad, but the lack
2013/8/20 David E. Wheeler
> On Aug 20, 2013, at 3:18 PM, Pavel Stehule
> wrote:
>
> > can you show some examples, please
>
> This is not dissimilar to what I am actually doing:
>
> CREATE TABLE foo (id SERIAL PRIMARY KEY, name TEXT);
>
> CREATE OR REPLACE FUNCTION shipit (
> VAR
Hi,
2013-08-19 21:52 keltezéssel, Boszormenyi Zoltan írta:
2013-08-19 21:21 keltezéssel, Karol Trzcionka írta:
W dniu 19.08.2013 19:56, Boszormenyi Zoltan pisze:
* Does it apply cleanly to the current git master?
No. There's a reject in src/backend/optimizer/plan/initsplan.c
Thank you, merge
On Aug 20, 2013, at 3:18 PM, Pavel Stehule wrote:
> can you show some examples, please
This is not dissimilar to what I am actually doing:
CREATE TABLE foo (id SERIAL PRIMARY KEY, name TEXT);
CREATE OR REPLACE FUNCTION shipit (
VARIADIC things TEXT[]
) RETURNS BOOL LANGUAGE
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> On Tue, Aug 20, 2013 at 6:21 PM, Stephen Frost wrote:
> > I'm not particularly set on this.. Why not create the file initially?
>If by default this feature needs to be disabled, then it is not
> must to have at initdb time.
I don't see how the
2013/8/20 David E. Wheeler
> On Aug 20, 2013, at 3:05 PM, Pavel Stehule
> wrote:
>
> > When you would to ignore result, then you should to use a PERFORM -
> actually, it is limited now and should be fixed. Have no problem with it.
>
> Glad to have you on board. :-)
>
> > I don't would to enable
On Aug 20, 2013, at 3:05 PM, Pavel Stehule wrote:
> When you would to ignore result, then you should to use a PERFORM - actually,
> it is limited now and should be fixed. Have no problem with it.
Glad to have you on board. :-)
> I don't would to enable a free unbound statement that returns res
On Tue, Aug 20, 2013 at 6:21 PM, Stephen Frost wrote:
> * Amit Kapila (amit.kapil...@gmail.com) wrote:
>> Okay, let us decide how things will be if we disable by default:
>>1. initdb won't create any empty auto file, rather the file will be
>> created first time user uses ALTER SYSTEM.
>
> I'm
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Amit Kapila escribió:
> >3. postgresql.conf will contain include directive in below form:
> >#include = 'postgresql.auto.conf'
> >Whenever user wants to use Alter System, he needs to enable it
> > after first time using ALTER
2013/8/20 David E. Wheeler
> On Aug 20, 2013, at 2:53 PM, Pavel Stehule
> wrote:
>
> >> I am passing the values returned from a CTE to a call to pg_notify(). I
> do not care to collect the output of pg_notify(), which returns VOID.
> >
> > it is little bit different issue - PL/pgSQL doesn't chec
On Aug 20, 2013, at 2:53 PM, Pavel Stehule wrote:
>> I am passing the values returned from a CTE to a call to pg_notify(). I do
>> not care to collect the output of pg_notify(), which returns VOID.
>
> it is little bit different issue - PL/pgSQL doesn't check if returned type is
> VOID - it ca
On 8/20/13 2:53 PM, Pavel Stehule wrote:
2013/8/20 David E. Wheeler
I am passing the values returned from a CTE to a call to pg_notify(). I do
not care to collect the output of pg_notify(), which returns VOID.
it is little bit different issue - PL/pgSQL doesn't check if returned type
is VOID
2013/8/20 David E. Wheeler
> On Aug 20, 2013, at 2:41 PM, Pavel Stehule
> wrote:
>
> > yes, in this context you should not use a PERFORM
> >
> > PL/pgSQL protect you before useless queries - so you can use a CTE
> without returned result directly or CTE with result via PERFORM statement
> (and i
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> Okay, let us decide how things will be if we disable by default:
>1. initdb won't create any empty auto file, rather the file will be
> created first time user uses ALTER SYSTEM.
I'm not particularly set on this.. Why not create the file initia
On Tue, Aug 20, 2013 at 7:44 AM, Pavel Stehule wrote:
>
>
>
> 2013/8/20 Merlin Moncure
>>
>> On Tue, Aug 20, 2013 at 7:25 AM, Andres Freund
>> wrote:
>> > On 2013-08-20 14:15:55 +0200, David E. Wheeler wrote:
>> >> Hi Pavel,
>> >>
>> >> On Aug 20, 2013, at 2:11 PM, Pavel Stehule
>> >> wrote:
>>
On Aug 20, 2013, at 2:44 PM, Pavel Stehule wrote:
> I think the way forward is to remove the restriction such that data
> returning queries must be PERFORM'd
>
> I disagree, current rule has sense.
Perhaps a DECLARE FUNCTION attribute that turns off the functionality, then?
Best,
David
--
2013-08-20 14:35 keltezéssel, David E. Wheeler írta:
On Aug 20, 2013, at 2:31 PM, Pavel Stehule wrote:
but it works
postgres=# do $$begin with x as (select 10) insert into omega select * from x;
end;$$;
DO
But this does not:
david=# DO $$
david$# BEGIN
david$# PERFORM * FROM (
david$#
On Aug 20, 2013, at 2:41 PM, Pavel Stehule wrote:
> yes, in this context you should not use a PERFORM
>
> PL/pgSQL protect you before useless queries - so you can use a CTE without
> returned result directly or CTE with result via PERFORM statement (and in
> this case it must be unmodifing CTE
2013/8/20 Merlin Moncure
> On Tue, Aug 20, 2013 at 7:25 AM, Andres Freund
> wrote:
> > On 2013-08-20 14:15:55 +0200, David E. Wheeler wrote:
> >> Hi Pavel,
> >>
> >> On Aug 20, 2013, at 2:11 PM, Pavel Stehule
> wrote:
> >>
> >> >> david=# DO $$
> >> >> david$# BEGIN
> >> >> david$#
2013/8/20 David E. Wheeler
> On Aug 20, 2013, at 2:31 PM, Pavel Stehule
> wrote:
>
> > but it works
> >
> > postgres=# do $$begin with x as (select 10) insert into omega select *
> from x; end;$$;
> > DO
>
> But this does not:
>
> david=# DO $$
> david$# BEGIN
> david$# PERFORM * FROM (
> da
On Tue, Aug 20, 2013 at 7:25 AM, Andres Freund wrote:
> On 2013-08-20 14:15:55 +0200, David E. Wheeler wrote:
>> Hi Pavel,
>>
>> On Aug 20, 2013, at 2:11 PM, Pavel Stehule wrote:
>>
>> >> david=# DO $$
>> >> david$# BEGIN
>> >> david$# WITH now AS (SELECT now())
>> >> david$#
On Aug 20, 2013, at 2:31 PM, Pavel Stehule wrote:
> but it works
>
> postgres=# do $$begin with x as (select 10) insert into omega select * from
> x; end;$$;
> DO
But this does not:
david=# DO $$
david$# BEGIN
david$# PERFORM * FROM (
david$# WITH inserted AS (
david$#
2013/8/20 David E. Wheeler
> On Aug 20, 2013, at 2:24 PM, Marko Tiikkaja wrote:
>
> >> postgres=# DO $$
> >> BEGIN
> >>PERFORM * FROM (WITH now AS (SELECT now())
> >> SELECT * from now) x;
> >> END;
> >> $$;
> >> DO
> >
> > .. which doesn't work if you want to use table-modifying CTEs.
>
On Aug 20, 2013, at 2:24 PM, Marko Tiikkaja wrote:
>> postgres=# DO $$
>> BEGIN
>>PERFORM * FROM (WITH now AS (SELECT now())
>> SELECT * from now) x;
>> END;
>> $$;
>> DO
>
> .. which doesn't work if you want to use table-modifying CTEs.
Which, in fact, is exactly my use case (though no
2013/8/20 Andres Freund
> On 2013-08-20 14:15:55 +0200, David E. Wheeler wrote:
> > Hi Pavel,
> >
> > On Aug 20, 2013, at 2:11 PM, Pavel Stehule
> wrote:
> >
> > >> david=# DO $$
> > >> david$# BEGIN
> > >> david$# WITH now AS (SELECT now())
> > >> david$# PERFORM * from
On 8/20/13 2:21 PM, Pavel Stehule wrote:
2013/8/20 David E. Wheeler
Well, there ought to be *some* way to tell PL/pgSQL to discard the result.
Right now I am adding a variable to select into but never otherwise use.
Inelegant, IMHO. Perhaps I’m missing some other way to do it?
If so, it would
On 2013-08-20 14:15:55 +0200, David E. Wheeler wrote:
> Hi Pavel,
>
> On Aug 20, 2013, at 2:11 PM, Pavel Stehule wrote:
>
> >> david=# DO $$
> >> david$# BEGIN
> >> david$# WITH now AS (SELECT now())
> >> david$# PERFORM * from now;
> >> david$# END;
> >> david$#
2013/8/20 David E. Wheeler
> Hi Pavel,
>
> On Aug 20, 2013, at 2:11 PM, Pavel Stehule
> wrote:
>
> >> david=# DO $$
> >> david$# BEGIN
> >> david$# WITH now AS (SELECT now())
> >> david$# PERFORM * from now;
> >> david$# END;
> >> david$# $$;
> >> ERROR: synt
Hi Pavel,
On Aug 20, 2013, at 2:11 PM, Pavel Stehule wrote:
>> david=# DO $$
>> david$# BEGIN
>> david$# WITH now AS (SELECT now())
>> david$# PERFORM * from now;
>> david$# END;
>> david$# $$;
>> ERROR: syntax error at or near "PERFORM"
>> LINE 4: PE
Hello
2013/8/20 David E. Wheeler
> Hackers,
>
> This seems reasonable:
>
> david=# DO $$
> david$# BEGIN
> david$# WITH now AS (SELECT now())
> david$# SELECT * from now;
> david$# END;
> david$# $$;
> ERROR: query has no destination for result data
> HI
Hackers,
This seems reasonable:
david=# DO $$
david$# BEGIN
david$# WITH now AS (SELECT now())
david$# SELECT * from now;
david$# END;
david$# $$;
ERROR: query has no destination for result data
HINT: If you want to discard the results of a SELECT, use PE
Hi,
2013-08-04 15:20 keltezéssel, Dimitri Fontaine írta:
Thom Brown writes:
Could you please resubmit this without using SnapshotNow as it's no longer
supported?
Sure, sorry that I missed that, please find v12 attached.
Here's a review for this patch.
* Is the patch in a patch format which
Hi all,
Taking a look at PostgreSQL HEAD today, I noticed that currently
PostgreSQL allows "of" value as bool type value.
So user can execute the following SQL.
=# SET enbale_seqscan TO of;
And I read the source code related to parsing bool value.
It compare TWO characters "off" and the setting
>You're linking against a pre-9.0 copy of libpq.so.
Thanks for help :)
I got my mistake .
Regards,
Amul Sul
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/undefined-symbol-PQescapeLiteral-tp5767578p5767994.html
Sent from the PostgreSQL - hackers mailing list archi
Hello
we support syntax for INSERT and DELETE statements, that allows a simple
triggers for these statements.
CREATE FUNCTION trg_insert()
RETURNS trigger AS $$
BEGIN
INSERT INTO target_tbl VALUES(NEW.*)
RETURN NULL;
END;
$$ LANGUAGE plpgsql;
* is not allowed in DELETE, but we can use a virt
83 matches
Mail list logo
