2013/2/5 Hannu Krosing :
> On 01/31/2013 11:20 PM, Andrew Dunstan wrote:
>>
>>
>> I'm happy to take opinions about this, and I expected
>> some bikeshedding, but your reaction is contrary to
>> everything others have told me. Mostly they love the operators.
>
> What I would really like is if we ext
2013/2/4 Robert Haas :
> On Mon, Feb 4, 2013 at 1:06 PM, Simon Riggs wrote:
>> On 2 January 2013 22:51, Robert Haas wrote:
>>> On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule
>>> wrote:
I am not sure, but maybe is time to introduce ANSI SQL syntax for
functions' named parameters
On Mon, Feb 4, 2013 at 10:52 PM, Tom Lane wrote:
> Phil Sorber writes:
>> get_progname() returns a strdup()'d value. Shouldn't it then be simply
>> char * and not const char *? Otherwise free() complains loudly without
>> a cast.
>
> I don't believe that callers should be trying to free() the res
Phil Sorber writes:
> get_progname() returns a strdup()'d value. Shouldn't it then be simply
> char * and not const char *? Otherwise free() complains loudly without
> a cast.
I don't believe that callers should be trying to free() the result.
Whether it's been strdup'd or not is not any of their
Per the support policy at
http://www.postgresql.org/support/versioning/
the 8.3.x branch has an EOL date of February 2013.
That means that, barring discovery of a bug so bad that we decide to
make a fresh set of update releases within the month, the just-wrapped
8.3.23 is the last release in the 8
Kohei KaiGai wrote:
> Let me confirm a significant point. Do you never plan a feature
> that allows to update/refresh materialized-views out of user
> session?
Currently only the owner of the MV or a database superuser can
refresh it, and the refresh is run with the permissions of the MV
owner.
Tom Lane wrote:
> Alvaro Herrera writes:
> > pg_xlogdump needs access to the *_desc functions for each rmgr. We
> > already moved forward quite a bit by splitting those functions out of
> > their containing files; so now they are compilable separately. Good.
> > The remaining task is enabling th
On 2013-02-04 17:27:39 -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > pg_xlogdump needs access to the *_desc functions for each rmgr. We
> > already moved forward quite a bit by splitting those functions out of
> > their containing files; so now they are compilable separately. Good.
> > The
On 01/31/2013 11:20 PM, Andrew Dunstan wrote:
I'm happy to take opinions about this, and I expected
some bikeshedding, but your reaction is contrary to
everything others have told me. Mostly they love the operators.
What I would really like is if we extended postgresql core and made
a few more
get_progname() returns a strdup()'d value. Shouldn't it then be simply
char * and not const char *? Otherwise free() complains loudly without
a cast.
diff --git a/src/include/port.h b/src/include/port.h
new file mode 100644
index 99d3a9b..2d6a435
*** a/src/include/port.h
--- b/src/include/port.h
*
There was some discussion about unifying backend and frontend
code/headers for palloc et al, particularly so that programs that want
to mix both can be easily compiled; see
http://www.postgresql.org/message-id/20130118150629.gc29...@alap2.anarazel.de
for what I believe to be the latest and greates
Tomas Vondra writes:
> I've managed to further simplify the test-case, and I've verified that
> it's reproducible on current 9.2 and 9.3 branches.
Yeah, I've been able to reproduce it as well. I found what I thought
might be the bug: gbt_var_bin_union() looks like it does the wrong thing
if both
Alvaro Herrera writes:
> pg_xlogdump needs access to the *_desc functions for each rmgr. We
> already moved forward quite a bit by splitting those functions out of
> their containing files; so now they are compilable separately. Good.
> The remaining task is enabling the code to find those funct
Jeff Janes writes:
> On Sat, Feb 2, 2013 at 5:25 AM, Andres Freund wrote:
> If the release notes are not already baked in, I would suggest this wording:
> + The main consequence of this mistake is that it
> + caused full-table vacuuming scans to occur much more frequently
> + than
On Sat, Feb 2, 2013 at 5:25 AM, Andres Freund wrote:
> On 2013-02-01 15:09:34 -0800, Jeff Janes wrote:
>> On Fri, Feb 1, 2013 at 2:34 PM, Andres Freund wrote:
>> > On 2013-02-01 14:05:46 -0800, Jeff Janes wrote:
>>
>> >> As far as I can tell this bug kicks in when your cluster gets to be
>> >> ol
On 4 February 2013 15:52, Robert Haas wrote:
> On Sun, Feb 3, 2013 at 5:25 PM, Simon Riggs wrote:
>> There is a bug in hot_standby_feedback that causes the xmin of the
>> walsender process to not be reset when hot_standby_feedback is turned
>> off after it had previously sent at least one feedbac
On 02/04/2013 04:19 PM, Daniel Farina wrote:
On Mon, Feb 4, 2013 at 12:37 PM, Andrew Dunstan wrote:
On 02/04/2013 03:16 PM, Daniel Farina wrote:
On Mon, Feb 4, 2013 at 11:38 AM, Robert Haas
wrote:
On Mon, Feb 4, 2013 at 11:10 AM, Andrew Dunstan
wrote:
On 02/04/2013 10:47 AM, Robert Haas w
Simon Riggs wrote:
> On 4 February 2013 20:57, Alvaro Herrera wrote:
>
> > pg_xlogdump needs access to the *_desc functions for each rmgr. We
> > already moved forward quite a bit by splitting those functions out of
> > their containing files; so now they are compilable separately. Good.
> > Th
On Mon, Feb 4, 2013 at 12:37 PM, Andrew Dunstan wrote:
>
> On 02/04/2013 03:16 PM, Daniel Farina wrote:
>>
>> On Mon, Feb 4, 2013 at 11:38 AM, Robert Haas
>> wrote:
>>>
>>> On Mon, Feb 4, 2013 at 11:10 AM, Andrew Dunstan
>>> wrote:
On 02/04/2013 10:47 AM, Robert Haas wrote:
>
>
On Mon, Feb 4, 2013 at 2:10 PM, Andrew Dunstan wrote:
>
>> My only remaining nit with the proposal is with json_unnest().
>>
>> SQL unnest() produces list of scalars regardless of dimensionality --
>> json unnest unwraps one level only (contrast: pl/pgsql array 'slice').
>> So I think 'json_arra
On 4 February 2013 20:57, Alvaro Herrera wrote:
> pg_xlogdump needs access to the *_desc functions for each rmgr. We
> already moved forward quite a bit by splitting those functions out of
> their containing files; so now they are compilable separately. Good.
> The remaining task is enabling th
Hi,
I've managed to further simplify the test-case, and I've verified that
it's reproducible on current 9.2 and 9.3 branches.
This is the necessary table structure:
---
CREATE TABLE test (
idTEXT,
valid TSRAN
Hi,
pg_xlogdump needs access to the *_desc functions for each rmgr. We
already moved forward quite a bit by splitting those functions out of
their containing files; so now they are compilable separately. Good.
The remaining task is enabling the code to find those functions in the
first place; cu
Robert Haas writes:
> On Fri, Feb 1, 2013 at 5:13 PM, Peter Eisentraut wrote:
>>> I wonder whether it'd not be a better idea to forbid specifying
>>> pg_catalog as the target schema for relocatable extensions.
We should do that, yes. Rationale: it's only documenting an existing
restriction that
On Mon, Feb 4, 2013 at 3:37 PM, Alvaro Herrera wrote:
> Gurjeet Singh wrote:
> > On Mon, Feb 4, 2013 at 2:38 PM, Alvaro Herrera >wrote:
> >
> > > I just noticed that contrib programs don't build in USE_PGXS=1
> > > environment:
> > >
> > > $ pwd
> > > /pgsql/build/HEAD/contrib/pg_upgrade
> > > $
Gurjeet Singh wrote:
> On Mon, Feb 4, 2013 at 2:38 PM, Alvaro Herrera
> wrote:
>
> > I just noticed that contrib programs don't build in USE_PGXS=1
> > environment:
> >
> > $ pwd
> > /pgsql/build/HEAD/contrib/pg_upgrade
> > $ LC_ALL=C USE_PGXS=1 make
> > make: *** No rule to make target `check.o'
On 02/04/2013 03:16 PM, Daniel Farina wrote:
On Mon, Feb 4, 2013 at 11:38 AM, Robert Haas wrote:
On Mon, Feb 4, 2013 at 11:10 AM, Andrew Dunstan wrote:
On 02/04/2013 10:47 AM, Robert Haas wrote:
The SQL standards considerations seem worth thinking about, too.
We've certainly gone through a
On 4 February 2013 19:53, Robert Haas wrote:
> This seems pretty close to an accusation of bad faith, which I don't
> believe to be present.
Robert, this is not an accusation of bad faith, just an observation
that we can move forwards more quickly.
I understand completely why you wish to make s
On Mon, Feb 4, 2013 at 2:38 PM, Alvaro Herrera wrote:
> I just noticed that contrib programs don't build in USE_PGXS=1
> environment:
>
> $ pwd
> /pgsql/build/HEAD/contrib/pg_upgrade
> $ LC_ALL=C USE_PGXS=1 make
> make: *** No rule to make target `check.o', needed by `pg_upgrade'. Stop.
>
FWIW,
On Mon, Feb 4, 2013 at 11:38 AM, Robert Haas wrote:
> On Mon, Feb 4, 2013 at 11:10 AM, Andrew Dunstan wrote:
>> On 02/04/2013 10:47 AM, Robert Haas wrote:
>>>
>>>
>>> The SQL standards considerations seem worth thinking about, too.
>>> We've certainly gone through a lot of pain working toward eli
On 02/04/2013 02:59 PM, Merlin Moncure wrote:
On Mon, Feb 4, 2013 at 12:07 PM, Andrew Dunstan wrote:
On 02/04/2013 12:57 PM, Merlin Moncure wrote:
*) it's bad enough that we drift from sql naming conventions and all
type manipulation functions (except in hstore) with type name.
json_get etc.
On Mon, Feb 4, 2013 at 11:38 AM, Robert Haas wrote:
>
> I suspect both of those are pretty safe from an SQL standards point of
> view. Of course, as Tom is often wont to point out, the SQL standards
> committee sometimes does bizarre things, so nothing's perfect, but I'd
> be rather shocked if an
On Mon, Feb 4, 2013 at 12:07 PM, Andrew Dunstan wrote:
>
> On 02/04/2013 12:57 PM, Merlin Moncure wrote:
>
>> *) it's bad enough that we drift from sql naming conventions and all
>> type manipulation functions (except in hstore) with type name.
>> json_get etc. at least using operators allow avo
On Mon, Feb 4, 2013 at 1:06 PM, Simon Riggs wrote:
> On 2 January 2013 22:51, Robert Haas wrote:
>> On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule
>> wrote:
>>> I am not sure, but maybe is time to introduce ANSI SQL syntax for
>>> functions' named parameters
>>>
>>> It is defined in ANSI SQL 2
On Mon, Feb 4, 2013 at 11:10 AM, Andrew Dunstan wrote:
> On 02/04/2013 10:47 AM, Robert Haas wrote:
>>
>>
>> The SQL standards considerations seem worth thinking about, too.
>> We've certainly gone through a lot of pain working toward eliminating
>> => as an operator name, and if the SQL standard
I just noticed that contrib programs don't build in USE_PGXS=1
environment:
$ pwd
/pgsql/build/HEAD/contrib/pg_upgrade
$ LC_ALL=C USE_PGXS=1 make
make: *** No rule to make target `check.o', needed by `pg_upgrade'. Stop.
$ LC_ALL=C make
[works]
Is this expected?
--
Álvaro Herrera
On 02/04/2013 12:57 PM, Merlin Moncure wrote:
*) it's bad enough that we drift from sql naming conventions and all
type manipulation functions (except in hstore) with type name.
json_get etc. at least using operators allow avoiding some of that
unnecessary verbosity. what's next: text_concat
On 2 January 2013 22:51, Robert Haas wrote:
> On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule
> wrote:
>> I am not sure, but maybe is time to introduce ANSI SQL syntax for
>> functions' named parameters
>>
>> It is defined in ANSI SQL 2011
>>
>> CALL P (B => 1, A => 2)
>>
>> instead PostgreSQL
Andres Freund wrote:
> On 2013-02-04 14:55:56 -0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> > > On 2013-02-04 13:22:26 -0300, Alvaro Herrera wrote:
> >
> > > > +typedef struct RmgrDescData
> > > > +{
> > > > + void(*rm_desc) (StringInfo buf, uint8 xl_info, char
> > > >
On 2013-02-04 14:55:56 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2013-02-04 13:22:26 -0300, Alvaro Herrera wrote:
>
> > > +typedef struct RmgrDescData
> > > +{
> > > + void(*rm_desc) (StringInfo buf, uint8 xl_info, char *rec);
> > > +} RmgrDescData;
> > > +
> > > +exte
On Mon, Feb 4, 2013 at 10:18 AM, Benedikt Grundmann
wrote:
>
>
>
> On Mon, Feb 4, 2013 at 4:10 PM, Andrew Dunstan wrote:
>>
>>
>> On 02/04/2013 10:47 AM, Robert Haas wrote:
>>>
>>>
>>> The SQL standards considerations seem worth thinking about, too.
>>> We've certainly gone through a lot of pain
Andres Freund wrote:
> On 2013-02-04 13:22:26 -0300, Alvaro Herrera wrote:
> > +typedef struct RmgrDescData
> > +{
> > + void(*rm_desc) (StringInfo buf, uint8 xl_info, char *rec);
> > +} RmgrDescData;
> > +
> > +extern const RmgrDescData RmgrDescTable[];
> > +
>
> I think we would a
2013/2/4 Gavin Flower :
> On 04/02/13 21:55, Pavel Stehule wrote:
>
> 2013/1/2 Robert Haas :
>
> On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule
> wrote:
>
> I am not sure, but maybe is time to introduce ANSI SQL syntax for
> functions' named parameters
>
> It is defined in ANSI SQL 2011
>
> CALL
On Feb 4, 2013, at 8:10 AM, Andrew Dunstan wrote:
> My suggestion would be ~> and ~>>. I know David Wheeler didn't like that on
> the ground that some fonts elevate ~ rather than aligning it in the middle as
> most monospaced fonts do, but I'm tempted just to say "then use a different
> font."
2013/2/4 Kevin Grittner :
> Kohei KaiGai wrote:
>> 2013/2/3 Kevin Grittner :
>>> I'm hoping that someone familiar with sepgsql can review this
>>> portion of the materialized view patch and comment on whether it is
>>> the best approach for dealing with the integration of these two
>>> features.
On 04/02/13 21:55, Pavel Stehule wrote:
2013/1/2 Robert Haas :
On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule wrote:
I am not sure, but maybe is time to introduce ANSI SQL syntax for
functions' named parameters
It is defined in ANSI SQL 2011
CALL P (B => 1, A => 2)
instead PostgreSQL syn
On 2013-02-04 17:21:50 +, Simon Riggs wrote:
> On 4 February 2013 17:02, Andres Freund wrote:
>
> > I unfortunately don't yet see a robust way without storing the last used
> > horizon :(.
>
> We can't go backwards, but we can go forwards.
>
> We can move the next xid forwards by an amount
On 4 February 2013 17:02, Andres Freund wrote:
> I unfortunately don't yet see a robust way without storing the last used
> horizon :(.
We can't go backwards, but we can go forwards.
We can move the next xid forwards by an amount equal to the increase
in vacuum_defer_cleanup_age.
--
Simon Ri
On 2013-02-04 11:52:05 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I absolutely hate to suggest it, but what about storing the last
> > vacuum's xmin horizon in the main table's pg_class.options in the back
> > branches?
>
> Not workable. This would require a non-in-place update of the ta
Robert Haas writes:
> Taking a first look at this, I think the idea of pg_dropped_objects()
> is really pretty clever. I like it. I assure we will end up with
> several functions of this type eventually, so it might be good to
> adopt some kind of distinguishing naming convention for this type o
Andres Freund writes:
> I absolutely hate to suggest it, but what about storing the last
> vacuum's xmin horizon in the main table's pg_class.options in the back
> branches?
Not workable. This would require a non-in-place update of the table's
pg_class row (at least in cases where the option was
On 2013-02-04 11:07:17 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-02-01 19:24:02 -0500, Tom Lane wrote:
> >> And as for that, it's been pretty clear for awhile that allowing
> >> vacuum_defer_cleanup_age to change on the fly was a bad idea we'd
> >> eventually have to undo. The da
On 4 February 2013 16:07, Tom Lane wrote:
> Simon, would you revert the vacuum_defer_cleanup_age changes?
Will do
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
On 2013-02-04 13:22:26 -0300, Alvaro Herrera wrote:
>
> I didn't like this bit too much:
>
> > diff --git a/contrib/pg_xlogdump/tables.c b/contrib/pg_xlogdump/tables.c
> > new file mode 100644
> > index 000..e947e0d
> > --- /dev/null
> > +++ b/contrib/pg_xlogdump/tables.c
> > @@ -0,0 +1,78 @@
I didn't like this bit too much:
> diff --git a/contrib/pg_xlogdump/tables.c b/contrib/pg_xlogdump/tables.c
> new file mode 100644
> index 000..e947e0d
> --- /dev/null
> +++ b/contrib/pg_xlogdump/tables.c
> @@ -0,0 +1,78 @@
> +/*
> + * RmgrTable linked only to functions available outside of
On Mon, Feb 4, 2013 at 4:10 PM, Andrew Dunstan wrote:
>
> On 02/04/2013 10:47 AM, Robert Haas wrote:
>
>>
>> The SQL standards considerations seem worth thinking about, too.
>> We've certainly gone through a lot of pain working toward eliminating
>> => as an operator name, and if the SQL standard
On 02/04/2013 10:47 AM, Robert Haas wrote:
The SQL standards considerations seem worth thinking about, too.
We've certainly gone through a lot of pain working toward eliminating
=> as an operator name, and if the SQL standard has commandeered ->
for some purpose or other, I'd really rather not
Andres Freund writes:
> On 2013-02-01 19:24:02 -0500, Tom Lane wrote:
>> And as for that, it's been pretty clear for awhile that allowing
>> vacuum_defer_cleanup_age to change on the fly was a bad idea we'd
>> eventually have to undo. The day of reckoning has arrived: it needs
>> to be PGC_POSTMA
Kohei KaiGai wrote:
> 2013/2/3 Kevin Grittner :
>> I'm hoping that someone familiar with sepgsql can review this
>> portion of the materialized view patch and comment on whether it is
>> the best approach for dealing with the integration of these two
>> features. Basically, the patch as it stands
On Sun, Feb 3, 2013 at 5:25 PM, Simon Riggs wrote:
> There is a bug in hot_standby_feedback that causes the xmin of the
> walsender process to not be reset when hot_standby_feedback is turned
> off after it had previously sent at least one feedback message.
>
> Clearly, that is a bad thing and des
On Sun, Feb 3, 2013 at 9:05 PM, Andrew Dunstan wrote:
>>> Yeah, this is surely not a workable policy unless we first move all
>>> those planner smarts to apply to functions not operators. And rewrite
>>> all the index AM APIs to use functions not operators, too. Now this is
>>> something that's
On Sat, Feb 2, 2013 at 4:38 PM, Andres Freund wrote:
> On 2013-01-28 16:55:52 -0500, Steve Singer wrote:
>> If your using non-surragate /natural primary keys this tends to come up
>> occasionally due to data-entry errors or renames. I'm looking at this from
>> the point of view of what do I need
On Fri, Feb 1, 2013 at 12:33 PM, Pavan Deolasee
wrote:
> I can write a patch in next couple of days if we are willing to accept
> for this release. I think it should be fairly easy and non-intrusive.
I think it's too late to consider this for 9.3, but I think we should
entertain it for 9.4.
The
Hi Josh,
I was quite busy last few months and I didn't have time to devote to this
topic. I have read the feedbacks and want to make things move now.
I suggest, we can start by discussing the design of my solution:
https://wiki.postgresql.org/wiki/SQL2011Temporal
I expect any criticism and recom
Phil Sorber wrote:
> On Mon, Feb 4, 2013 at 10:16 AM, Alvaro Herrera
> wrote:
> > Phil Sorber wrote:
> >> On Mon, Feb 4, 2013 at 9:13 AM, Alvaro Herrera
> >> wrote:
> >
> >> > Uh, no existing code can use this new functionality? That seems
> >> > disappointing.
> >>
> >> I wrote this because I
On Mon, Feb 4, 2013 at 10:16 AM, Alvaro Herrera
wrote:
> Phil Sorber wrote:
>> On Mon, Feb 4, 2013 at 9:13 AM, Alvaro Herrera
>> wrote:
>
>> > Uh, no existing code can use this new functionality? That seems
>> > disappointing.
>>
>> I wrote this because I wanted to use it in pg_isready. I also
Phil Sorber wrote:
> On Mon, Feb 4, 2013 at 9:13 AM, Alvaro Herrera
> wrote:
> > Uh, no existing code can use this new functionality? That seems
> > disappointing.
>
> I wrote this because I wanted to use it in pg_isready. I also wrote
> something for pg_isready to get around not having this.
On Mon, Feb 4, 2013 at 9:13 AM, Alvaro Herrera wrote:
>
>> > On Feb 3, 2013 4:16 AM, "Phil Sorber" wrote:
>> >>
>> >> This patch came up from discussion about pg_isready.
>> >>
>> >> PQconninfoParseParams is similar to PQconninfoParse but takes two
>> >> arrays like PQconnectdbParams. It essentia
Kohei KaiGai escribió:
> 2013/2/3 Tom Lane :
> > Alvaro Herrera writes:
> >> [ pgsql-v9.3-alter-reworks.3-rename.v10.patch.gz ]
> >
> > Say ... I hadn't been paying too close attention to this patch, but
> > is there any particularly principled reason for it having unified
> > only 14 of the 29 ob
On Fri, Feb 1, 2013 at 4:08 PM, Robert Haas wrote:
> But even leaving that aside, I'm surprised to hear so many people
> dismissing SQL standards compliance so blithely. We've certainly
> spent a lot of blood, sweat, and tears on minor standards-compliance
> issues over they years - why is it OK
> > On Feb 3, 2013 4:16 AM, "Phil Sorber" wrote:
> >>
> >> This patch came up from discussion about pg_isready.
> >>
> >> PQconninfoParseParams is similar to PQconninfoParse but takes two
> >> arrays like PQconnectdbParams. It essentially exposes
> >> conninfo_array_parse().
> >>
> >> PQconninfod
The tweaks made by you seems fine. I'm good with it.
Regards,
Ali Dar
On Sun, Feb 3, 2013 at 8:04 PM, Dean Rasheed wrote:
> On 29 January 2013 15:34, Ali Dar wrote:
> > Please find attached the complete patch for alter rename rule. I have
> > followed all the suggestions.
>
> This looks good.
On Sat, Feb 2, 2013 at 09:55:29PM -0500, Phil Sorber wrote:
> >>> I think that output is important as do others up thread. I think it'd
> >>> be simpler to just disable dbname's ability to double as conninfo. If
> >>> we are looking for easy, that is.
> >>>
> >>> I don't mind duplicating the behav
> Can you check if you still see that behavior with REL9_2_STABLE?
Will do.
--
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/mailpref/pgsql-hackers
Hi Vlad,
I'm also interested in this topic and work on system-time temporal
extension. Here I wrote down design of my solution few months ago
https://wiki.postgresql.org/wiki/SQL2011Temporal. The idea is basically the
same as in your solution with some minor differences. For example:
- I use
On 2013-02-01 19:24:02 -0500, Tom Lane wrote:
> Robert Haas writes:
> > Having said that, I agree that a fix in GetOldestXmin() would be nice
> > if we could find one, but since the comment describes at least three
> > different ways the value can move backwards, I'm not sure that there's
> > real
On 2/3/13 10:06 PM, Tom Lane wrote:
Applied with corrections.
Thank you.
The xml expected output was still wrong - to do that part right, you
need to update xml.out with an xml-enabled build and xml_1.out with a
non-xml-enabled build.
Ahh. That explains a lot.
Regards,
Marko Tiikkaja
2013/2/3 Kevin Grittner :
> I'm hoping that someone familiar with sepgsql can review this> portion of the
> materialized view patch and comment on whether it is
> the best approach for dealing with the integration of these two
> features. Basically, the patch as it stands treats a materialized
>
On 02/04/2013 02:16 AM, Robert Haas wrote:
On Fri, Feb 1, 2013 at 5:13 PM, Peter Eisentraut wrote:
I wonder whether it'd not be a better idea to forbid specifying
pg_catalog as the target schema for relocatable extensions.
But that would be important, I think.
I understand the temptation to f
2013/1/2 Robert Haas :
> On Fri, Dec 28, 2012 at 11:22 AM, Pavel Stehule
> wrote:
>> I am not sure, but maybe is time to introduce ANSI SQL syntax for
>> functions' named parameters
>>
>> It is defined in ANSI SQL 2011
>>
>> CALL P (B => 1, A => 2)
>>
>> instead PostgreSQL syntax CALL ( B := 1,
80 matches
Mail list logo
