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
> 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
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 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
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 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 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,
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 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
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.
>
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: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
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
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
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
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
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: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
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
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
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
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
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,
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
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
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 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 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 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
"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
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:
> 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
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
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
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
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 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
>
> > 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 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
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
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 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
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
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/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
"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
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
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
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
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
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 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
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 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
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 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 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 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 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 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 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
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 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
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
64 matches
Mail list logo
