On Tue, Sep 25, 2012 at 5:36 PM, Peter Eisentraut wrote:
> On Mon, 2012-09-24 at 21:18 -0700, Daniel Farina wrote:
>> The gap between
>> pre-JSON-in-the-standard-library in Python, Ruby, et al and
>> post-JSON-in-stdlib was much smaller.
>
> Except in Python they renamed the thing.
By 'smaller' I
On 09/26/2012 01:02 AM, m...@rpzdesign.com wrote:
John:
Who has the money for oracle RAC or funding arrogant bastard Oracle
CEO Ellison to purchase another island?
Postgres needs CHEAP, easy to setup, self healing,
master-master-master-master and it needs it yesterday.
I was able to patch
Tom Lane writes:
> It's a bug. The event-trigger patch added EVENT as a new keyword, but
> forgot to list it in the unreserved_keywords production, which is
> necessary to make it actually act unreserved.
Oh. Oops. Sorry about that.
> I've committed a fix, and manually verified there are no oth
On 26 September 2012 15:47, Alvaro Herrera wrote:
>
> Really, as far as autovacuum is concerned, it would be much more useful
> to be able to reliably detect that a table has been recently vacuumed,
> without having to request a 10ms-recent pgstat snapshot. That would
> greatly reduce the amount
On 25.09.2012 18:27, Amit Kapila wrote:
If you feel it is must to do the comparison, we can do it in same way as we
identify for HOT?
Yeah. (But as discussed, I think it would be even better to just treat
the old and new tuple as an opaque chunk of bytes, and run them through
a generic delta
> On Thursday, September 27, 2012 4:12 PM Heikki Linnakangas wrote:
> On 25.09.2012 18:27, Amit Kapila wrote:
> > If you feel it is must to do the comparison, we can do it in same way
> > as we identify for HOT?
>
> Yeah. (But as discussed, I think it would be even better to just treat
> the old a
On Wed, Sep 26, 2012 at 1:46 PM, Tom Lane wrote:
> Also, on reflection I'm not sure about commandeering cast-to-json for
> this --- aren't we really casting to "json member" or something like
> that? The distinction between a container and its contents seems
> important here. With a container ty
On Wed, Sep 26, 2012 at 10:59 AM, Christopher Browne wrote:
> A different place where I wound up having to jump through considerable
> hoops when doing schema analytics was vis-a-vis identifying functions.
> I need to be able to compare schemas across databases, so oid-based
> identification of f
> On Thursday, September 27, 2012 9:12 AM Noah Misch wrote:
> On Mon, Sep 24, 2012 at 10:57:02AM +, Amit kapila wrote:
> > Rebased version of patch based on latest code.
>
> I like the direction you're taking with this patch; the gains are
> striking,
> especially considering the isolation of
On Wed, Sep 26, 2012 at 9:16 PM, Tom Lane wrote:
> Any objections?
None, and my apologies for the oversight.
I would really like to have a cross-check for duplicated OIDs, too.
After a couple of years I think I have learned most of the rules for
what stuff I need to cross-check before committing
On Thu, Sep 27, 2012 at 8:22 AM, Robert Haas wrote:
> On Wed, Sep 26, 2012 at 1:46 PM, Tom Lane wrote:
>> Also, on reflection I'm not sure about commandeering cast-to-json for
>> this --- aren't we really casting to "json member" or something like
>> that? The distinction between a container and
Excerpts from Kohei KaiGai's message of jue sep 27 01:06:41 -0300 2012:
> Hi Alvaro,
>
> Let me volunteer for reviewing, of course, but now pgsql_fdw is in my queue...
Sure, thanks -- keep in mind I entered this patch in the next
commitfest, so please do invest more effort in the ones in the
comm
On 09/27/2012 09:22 AM, Robert Haas wrote:
On Wed, Sep 26, 2012 at 1:46 PM, Tom Lane wrote:
Also, on reflection I'm not sure about commandeering cast-to-json for
this --- aren't we really casting to "json member" or something like
that? The distinction between a container and its contents see
Andrew Dunstan writes:
> On 09/27/2012 09:22 AM, Robert Haas wrote:
>> Maybe I am being too pedantic about this and there is a way to make it
>> all work nicely, but it sure feels like using the casting machinery
>> here is blending together two different concepts that are only
>> sometimes the sa
On Thu, Sep 27, 2012 at 10:09 AM, Andrew Dunstan wrote:
> So how about this suggestion: we'll look for a visible function named
> "as_json" or some such which has one parameter of the given type and returns
> json, and if it's present use it instead of the standard text
> representation. As an opt
Hm...
IMO,
'[1,2,3]'::json
'[1,2,3]'::text::json
'[1,2,3]'::int[]::json
are the same thing... (though I am not sure '[1,2,3]'::int[] is valid in
postgres...)
in js var o = JSON.parse(result_of_any_cast_above) should produce array of
3 integer
'[1,2,3]' is different then'"[1,2,3]"'
If there is
Hi,
This patch (psql_remove_include.patch) eliminates
the #include of psqlscan.c at the bottom of mainloop.c.
The attached patch uses the %top{} flex feature
introduced in flex 2.5.30 released 2003-4-1.
(See the NEWS file for flex.)
The good news is that config/programs.m4
requires flex >= 2.5
Excerpts from Simon Riggs's message of jue sep 27 06:51:28 -0300 2012:
> On 26 September 2012 15:47, Alvaro Herrera wrote:
> >
> > Really, as far as autovacuum is concerned, it would be much more useful
> > to be able to reliably detect that a table has been recently vacuumed,
> > without having t
"Karl O. Pinc" writes:
> This patch (psql_remove_include.patch) eliminates
> the #include of psqlscan.c at the bottom of mainloop.c.
I don't really see that this is enough of an improvement to justify
depending on a non-portable flex feature.
> I'm thinking of exposing enough of the psql parser
On 09/27/2012 10:07:48 AM, Tom Lane wrote:
> "Karl O. Pinc" writes:
> > This patch (psql_remove_include.patch) eliminates
> > the #include of psqlscan.c at the bottom of mainloop.c.
>
> I don't really see that this is enough of an improvement to justify
> depending on a non-portable flex feature
Excerpts from Karl O. Pinc's message of jue sep 27 12:29:53 -0300 2012:
> The reason I want this is because I don't want to have to
> rewrite the sql parser in PHP for inclusion in phpPgAdmin.
> (I did this once, and it was such a big ugly patch
> it never got around to getting into the mainline p
On 09/27/12 8:41 AM, Alvaro Herrera wrote:
But I think I see what Tom objection to it is: if we "export" this
capability to libpq applications, then we set it in stone to a certain
extent: exactly how things are split would become part of the API, so to
speak. Upgrading to a newer libpq could br
On 24.09.2012 21:06, Fujii Masao wrote:
The patch could be applied cleanly and the compile could be successfully done.
Thanks for the testing!
But when I ran initdb, I got the following assertion error:
--
$ initdb -D data --locale=C --encoding=UTF-8
T
Alvaro Herrera writes:
> But I think I see what Tom objection to it is: if we "export" this
> capability to libpq applications, then we set it in stone to a certain
> extent: exactly how things are split would become part of the API, so to
> speak. Upgrading to a newer libpq could break applicati
On Wed, Sep 26, 2012 at 10:08 AM, Andrew Dunstan wrote:
> How many would EDB need for it to be useful?
Looks like we currently have about 160 hard-coded OIDs in our fork
that are not in PostgreSQL, across all catalogs. Actually, there are
probably some things we could do to reduce that number, w
On Tue, Sep 18, 2012 at 05:52:51PM +0200, Marco Nenciarini wrote:
> please find attached the refreshed v1 patch.
I perused this version in comparison to the last version I reviewed, finding
minor problems. First, a warning:
tablecmds.c: In function `ATExecAddConstraint':
tablecmds.c:5898: wa
>
> > I did like the alternative idea upthread of UUIDs for types which
> > would give them a virtually unlimited space.
>
> Yeah, me too. That doesn't require a centralized authority (hence, no
> debates here about whether a given extension is important enough to merit
> an allocation of a give
On 09/27/2012 11:02:42 AM, Tom Lane wrote:
> Alvaro Herrera writes:
> A larger point is that I don't believe this is actually going to help
> anybody, because of mismatch of requirements not only implementation
> language. JDBC couldn't use a libpq lexer implementation even
> without
> the lang
On 09/27/2012 11:02:42 AM, Tom Lane wrote:
> Rather, the problem is that the server might know about some newer
> lexical feature, and so might the application, but if libpq is behind
> the times then it's broken.
If the application knows about the newer feature and wants
to use it, is it unreas
On Sep 27, 2012 9:52 AM, "Robert Haas" wrote:
>
> On Wed, Sep 26, 2012 at 10:08 AM, Andrew Dunstan
wrote:
> > How many would EDB need for it to be useful?
>
> Looks like we currently have about 160 hard-coded OIDs in our fork
> that are not in PostgreSQL, across all catalogs. Actually, there are
Hello
2012/9/24 Heikki Linnakangas :
> Having read through this thread, the consensus seems to be that we don't
> want this patch as it is (and I agree with that).
>
> As I understand it, you are trying to solve two problems:
>
> 1. Passing parameters to a DO statement. You could quote the paramet
Hello
2012/9/21 Shigeru HANADA :
> Hi Pavel,
>
> (2012/09/21 2:01), Pavel Stehule wrote:
>>> - Is it intentional that \gset can set special variables such as
>>> AUTOCOMMIT and HOST? I don't see any downside for this behavior,
>>> because \set also can do that, but it is not documented nor tested
"Karl O. Pinc" writes:
> What I'm thinking of in libpq is the ability to give it big string
> with many sql statements and have it hand back each statement
> so the client can then submit it to the server for execution.
> What I really _want_ is to be able get a bit string of many
> sql statements
Excerpts from Noah Misch's message of mié sep 26 17:54:43 -0300 2012:
> I'm marking this patch Ready for Committer. I suggest backpatching it to 9.2;
> the patch corrects an oversight in 9.2 changes. There's more compatibility
> value in backpatching than in retaining distinct behavior for 9.2 on
"Karl O. Pinc" writes:
> On 09/27/2012 11:02:42 AM, Tom Lane wrote:
>> Rather, the problem is that the server might know about some newer
>> lexical feature, and so might the application, but if libpq is behind
>> the times then it's broken.
> If the application knows about the newer feature and
On Thu, Sep 27, 2012 at 2:34 PM, Magnus Hagander wrote:
> I'm not sure that's a way we really want to go down. How do we define which
> third party vendors would get to reserve oids? And how many? And under what
> other potential terms?
>
> Seems like we'd set ourselves up for endless discussions
On 09/27/2012 02:28:49 PM, Tom Lane wrote:
> "Karl O. Pinc" writes:
> > What I really _want_ is to be able get a bit string of many
> > sql statements from the user and return the results, statuses,
> > etc. of executing each statement. Just what psql does when,
> > say, fed a file from stdin.
>
On 27 September 2012 15:57, Alvaro Herrera wrote:
> Excerpts from Simon Riggs's message of jue sep 27 06:51:28 -0300 2012:
>> On 26 September 2012 15:47, Alvaro Herrera wrote:
>> >
>> > Really, as far as autovacuum is concerned, it would be much more useful
>> > to be able to reliably detect that
On Thu, Sep 27, 2012 at 10:02 PM, Robert Haas wrote:
> On Thu, Sep 27, 2012 at 2:34 PM, Magnus Hagander wrote:
>> I'm not sure that's a way we really want to go down. How do we define which
>> third party vendors would get to reserve oids? And how many? And under what
>> other potential terms?
>>
On 09/27/2012 10:36 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 09/27/2012 09:22 AM, Robert Haas wrote:
Maybe I am being too pedantic about this and there is a way to make it
all work nicely, but it sure feels like using the casting machinery
here is blending together two different concepts
Excerpts from Kohei KaiGai's message of lun sep 10 08:08:32 -0300 2012:
> As attached, I split off the original one into three portions; for set-schema,
> set-owner and rename-to. Please apply them in order of patch filename.
> Regarding to the error message, RenameErrorMsgAlreadyExists() was adde
Hello
I reduced this patch as just plpgsql (SPI) problem solution.
Correct generic solution needs a discussion about enhancing our libpq
interface - we can take a number of returned rows, but we should to
get number of processed rows too. A users should to parse this number
from completationTag,
On Tue, Sep 25, 2012 at 5:08 PM, Brian Weaver wrote:
> Unless I misread the code, the tar format and streaming xlog are
> mutually exclusive. Considering my normal state of fatigue it's not
> unlikely. I don't want to have to set my wal_keep_segments
> artificially high just for the backup
Correc
On Tue, Sep 25, 2012 at 4:07 AM, Tom Lane wrote:
> Brian Weaver writes:
>> While researching the way streaming replication works I was examining
>> the construction of the tar file header. By comparing documentation on
>> the tar header format from various sources I certain the following
>> patch
Magnus,
I probably just did a poor job of explaining what I wanted to try. I
was going to have the base backup open two connections; one to stream
the tar archive, the second to receive the wal files like
pg_receivexlog.
The wal files received on the second connection would be streamed to a
tempo
OK, here is my attempt at patching and correcting the issue in this
thread. I have done my best to test to ensure that hot standby,
pg_basebackup, and pg_restore of older files work without issues. I
think this might be a larger patch that expected, I took some
liberties of trying to clean up a bit
On Fri, Sep 28, 2012 at 12:12 AM, Brian Weaver wrote:
> Magnus,
>
> I probably just did a poor job of explaining what I wanted to try. I
> was going to have the base backup open two connections; one to stream
> the tar archive, the second to receive the wal files like
> pg_receivexlog.
This is wh
Magnus Hagander writes:
> On Tue, Sep 25, 2012 at 4:07 AM, Tom Lane wrote:
>> I'm a bit concerned about backwards compatibility issues. It looks to
>> me like existing versions of pg_restore will flat out reject files that
>> have a spec-compliant "ustar\0" MAGIC field. Is it going to be
>> suf
On Fri, Sep 28, 2012 at 12:30 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Sep 25, 2012 at 4:07 AM, Tom Lane wrote:
>>> I'm a bit concerned about backwards compatibility issues. It looks to
>>> me like existing versions of pg_restore will flat out reject files that
>>> have a spec-c
Brian Weaver writes:
> OK, here is my attempt at patching and correcting the issue in this
> thread. I have done my best to test to ensure that hot standby,
> pg_basebackup, and pg_restore of older files work without issues. I
> think this might be a larger patch that expected, I took some
> liber
Magnus Hagander writes:
> Ah, yeah, that should also work I guess. But you could also just leave
> the the data in the temporary tarfile the whole time. IIRC, you can
> just cat one tarfile to the end of another one, right?
Not if they're written according to spec, I think. There is an EOF
marke
On 09/27/2012 06:30 PM, Tom Lane wrote:
Magnus Hagander writes:
On Tue, Sep 25, 2012 at 4:07 AM, Tom Lane wrote:
I'm a bit concerned about backwards compatibility issues. It looks to
me like existing versions of pg_restore will flat out reject files that
have a spec-compliant "ustar\0" MAGI
On Fri, Sep 28, 2012 at 12:45 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> Ah, yeah, that should also work I guess. But you could also just leave
>> the the data in the temporary tarfile the whole time. IIRC, you can
>> just cat one tarfile to the end of another one, right?
>
> Not if they're
Andrew Dunstan writes:
> On 09/27/2012 06:30 PM, Tom Lane wrote:
>> Having said all that, I don't think we have a lot of choices here.
>> A "tar format" output option that isn't actually tar format has hardly
>> any excuse to live at all.
> I agree, but it's possibly worth pointing out that GNU t
On Fri, Sep 28, 2012 at 12:55 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 09/27/2012 06:30 PM, Tom Lane wrote:
>>> Having said all that, I don't think we have a lot of choices here.
>>> A "tar format" output option that isn't actually tar format has hardly
>>> any excuse to live at all.
>
On 09/27/2012 09:18 PM, Andrew Dunstan wrote:
On 09/27/2012 10:36 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 09/27/2012 09:22 AM, Robert Haas wrote:
Maybe I am being too pedantic about this and there is a way to make it
all work nicely, but it sure feels like using the casting machinery
h
Magnus Hagander writes:
> On Fri, Sep 28, 2012 at 12:55 AM, Tom Lane wrote:
>> I think it's clear that we should make all versions of pg_restore accept
>> either spelling of the magic string. It's less clear that we should
>> change the output of pg_dump in back branches though. I think the onl
On 9/26/12 6:17 PM, m...@rpzdesign.com wrote:
> Josh:
>
> The good part is you are the first person to ask for a copy
> and I will send you the hook code that I have and you can be a good sport
> and put it on GitHub, that is great, you can give us both credit for a
> joint effort, I do the code,
On 09/27/2012 06:58 PM, Hannu Krosing wrote:
On 09/27/2012 09:18 PM, Andrew Dunstan wrote:
On 09/27/2012 10:36 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 09/27/2012 09:22 AM, Robert Haas wrote:
Maybe I am being too pedantic about this and there is a way to
make it
all work nicely, but
On 27-09-2012 01:30, Amit Kapila wrote:
> I understood this point, but currently in documentation of Timelines, this
> usecase is not documented (Section 24.3.5).
>
Timeline documentation was written during PITR implementation. There wasn't SR
yet. AFAICS it doesn't cite SR but is sufficiently ge
On Thu, Sep 27, 2012 at 6:43 PM, Tom Lane wrote:
> Brian Weaver writes:
>> OK, here is my attempt at patching and correcting the issue in this
>> thread. I have done my best to test to ensure that hot standby,
>> pg_basebackup, and pg_restore of older files work without issues. I
>> think this mi
Example:
create temporary table foo (a int);
insert into foo values (1);
alter role peter set temp_buffers = 120;
ERROR: 22023: invalid value for parameter "temp_buffers": 120
DETAIL: "temp_buffers" cannot be changed after any temporary tables
have been accessed in the session.
Another example:
> On Friday, September 28, 2012 2:28 AM Pavel Stehule wrote:
> Hello
>
> I reduced this patch as just plpgsql (SPI) problem solution.
>
> Correct generic solution needs a discussion about enhancing our libpq
> interface - we can take a number of returned rows, but we should to get
> number of pro
2012/9/28 Amit Kapila :
>> On Friday, September 28, 2012 2:28 AM Pavel Stehule wrote:
>> Hello
>>
>> I reduced this patch as just plpgsql (SPI) problem solution.
>>
>> Correct generic solution needs a discussion about enhancing our libpq
>> interface - we can take a number of returned rows, but we
64 matches
Mail list logo
