Takahiro Itagaki wrote:
> KaiGai Kohei wrote:
>
>> The attached patch fixes these matters.
>
> I'll start to check it.
Thanks,
>> We have to reference pg_largeobject_metadata to check whether a certain
>> large objct exists, or not.
>
> What is the situation where there is a row in pg_lar
KaiGai Kohei wrote:
> The attached patch fixes these matters.
I'll start to check it.
> We have to reference pg_largeobject_metadata to check whether a certain
> large objct exists, or not.
What is the situation where there is a row in pg_largeobject_metadata
and no corresponding rows in
KaiGai Kohei wrote:
> Takahiro Itagaki wrote:
>> KaiGai Kohei wrote:
>>
>>> Tom Lane wrote:
Takahiro Itagaki writes:
>pg_largeobject should not be readable by the
>public, since the catalog contains data in large objects of all users.
This is going to be a problem, becau
Jaime Casanova wrote:
> besides if a normal user can read from pg_class why we deny pg_largeobject
pg_class and pg_largeobject_metadata contain only metadata of objects.
Tables and pg_largeobject contain actual data of the objects. A normal user
can read pg_class, but cannot read contents of ta
Robert Haas wrote:
> On Thu, Dec 10, 2009 at 11:45 PM, Tom Lane wrote:
>> If you're not prepared to assume that we're going to do row level
>> security, it's not apparent why we should be embarking on this course
>> at all. And if you do assume that, I strongly believe that my effort
>> estimate
On Thu, Dec 10, 2009 at 10:39 PM, Stephen Frost wrote:
> Let's start by taking the patch I reviewed and splitting up
> security/access_control.c along object lines. Of course, the individual
> security/_ac.c files would only include the .h's that are
> necessary. This would be a set of much smal
Takahiro Itagaki wrote:
> KaiGai Kohei wrote:
>
>> Tom Lane wrote:
>>> Takahiro Itagaki writes:
pg_largeobject should not be readable by the
public, since the catalog contains data in large objects of all users.
>>> This is going to be a problem, because it will break application
On Thu, Dec 10, 2009 at 11:45 PM, Tom Lane wrote:
> If you're not prepared to assume that we're going to do row level
> security, it's not apparent why we should be embarking on this course
> at all. And if you do assume that, I strongly believe that my effort
> estimate above is on the optimisti
KaiGai Kohei wrote:
> Tom Lane wrote:
> > Takahiro Itagaki writes:
> >>pg_largeobject should not be readable by the
> >>public, since the catalog contains data in large objects of all users.
> >
> > This is going to be a problem, because it will break applications that
> > expect to be
On Thu, Dec 10, 2009 at 11:33 PM, Jaime Casanova
wrote:
> On Thu, Dec 10, 2009 at 11:22 PM, Tom Lane wrote:
>>
>> My bet is that the real problem was a build inconsistency in
>> the backend. Does "make distclean" and rebuild make it go away?
>>
>
> actually it was a clean build just after a cvs
2009/12/10 KaiGai Kohei :
>
> If so, we can inject a hardwired rule to prevent to select pg_largeobject
> when lo_compat_privileges is turned off, instead of REVOKE ALL FROM PUBLIC.
>
it doesn't seem like a good idea to make that GUC act like a GRANT or
REVOKE on the case of pg_largeobject.
beside
Tom Lane wrote:
> Takahiro Itagaki writes:
>> OK, I'll add the following description in the documentation of
>> pg_largeobject.
>
>>pg_largeobject should not be readable by the
>>public, since the catalog contains data in large objects of all users.
>
> This is going to be a problem, be
On Wed, Dec 9, 2009 at 9:04 AM, Zdenek Kotala wrote:
> Bernd Helmle píše v út 08. 12. 2009 v 22:06 +0100:
>>
>> --On 8. Dezember 2009 15:51:52 -0500 Greg Smith
>> wrote:
>>
>> > Try this instead, which will give you a test where checkpoints have a
>> > minimal impact, but lots of memory will be t
Tom Lane wrote:
It's been perfectly clear since day one, and was reiterated as recently
as today
http://archives.postgresql.org/message-id/4b21757e.7090...@2ndquadrant.com
that what the security community wants is row-level security.
I think David Quigley's comments from earlier today summarize
Robert Haas writes:
> On Thu, Dec 10, 2009 at 5:08 PM, Tom Lane wrote:
>> My guess is that a credible SEPostgres offering will require a long-term
>> amount of work at least equal to, and very possibly a good deal more
>> than, what it took to make a native Windows port.
> The SEPostgres communi
On Thu, Dec 10, 2009 at 11:22 PM, Tom Lane wrote:
>
> My bet is that the real problem was a build inconsistency in
> the backend. Does "make distclean" and rebuild make it go away?
>
actually it was a clean build just after a cvs co (not an updated
tree), i build the binaries and installed it in
On Thu, Dec 10, 2009 at 9:35 PM, Takahiro Itagaki
wrote:
> Anyway, a revised patch according to the comments is attached.
> The new text format is:
> Buffers: shared hit=675 read=968, temp read=1443 written=1443
> * Zero values are omitted. (Non-text formats could have zero values.)
> * Ren
Takahiro Itagaki writes:
> OK, I'll add the following description in the documentation of pg_largeobject.
>pg_largeobject should not be readable by the
>public, since the catalog contains data in large objects of all users.
This is going to be a problem, because it will break application
Greg Smith writes:
> The "-j" option is the recent addition to pgbench that causes it to
> launch multiple client threads when enabled, each handling a subset of
> the transactions. There's blocks of codes in pgbench.c now that depend
> on having sane values for thread safety in libpq. That i
Stephen Frost wrote:
* Greg Smith (g...@2ndquadrant.com) wrote:
I have to be honest and say that I'm not optimistic that this is
possible or even a good idea to accomplish in the time remaining during
this release.
While I agree with you, I wish you hadn't brought it up. :) Mostly
KaiGai Kohei wrote:
> What's your opinion about:
> long desc: When turned on, privilege checks on large objects perform with
> backward compatibility as 8.4.x or earlier releases.
I updated the description as your suggest.
Applied with minor editorialization,
mainly around tab-c
* Greg Smith (g...@2ndquadrant.com) wrote:
> I personally feel that Steven
> Frost's recent comments here about how the PostgreSQL code makes this
> harder than it should be really cuts to the core of a next step here.
> The problem facing us isn't "is SEPostgreSQL the right solution for
>
Robert Haas writes:
> Hilariously enough, that's exactly what we used to do. I am leaning
> toward the view that we should revert all the ASCII output format
> changes vs. 8.4 and let people use the new unicode mode if they want
> all the spiffy bells and whistles.
There are clearly use-cases fo
Takahiro Itagaki wrote:
> KaiGai Kohei wrote:
>
>>> we still allow "SELECT * FROM pg_largeobject" ...right?
>> It can be solved with revoking any privileges from anybody in the initdb
>> phase. So, we should inject the following statement for setup_privileges().
>>
>> REVOKE ALL ON pg_largeobje
On Thu, Dec 10, 2009 at 8:11 PM, Bruce Momjian wrote:
> Andrew Dunstan wrote:
>>
>>
>> Tom Lane wrote:
>> > regression=# select
>> > E'xxx\nxx\n'
>> > as a, 1 as b;
>> > a
Robert Haas wrote:
> On Thu, Dec 10, 2009 at 8:39 PM, Andrew Dunstan wrote:
> > OK, I've committed the YAML stuff, so who is working on the auto-explain
> > bug? Robert?
>
> I'm going to propose fixing this in what seems to me to be the
> simplest possible way, per the attached. Anyone want t
David P. Quigley wrote:
> On Thu, 2009-12-10 at 17:08 -0500, Tom Lane wrote:
>> Robert Haas writes:
>>> Unlike Tom (I think), I do believe that there is demand (possibly only
>>> from a limited number of people, but demand all the same) for this
>>> feature.
>> Please note that I do not think ther
Greg Smith wrote:
> It's funny; we started out this CommitFest with me scrambling to find
> someone, anyone, willing to review the latest SE-PostgreSQL patch,
> knowing it was a big job and few were likely to volunteer. Then
> schedules lined up just right, and last night I managed to get a gre
On Thu, Dec 10, 2009 at 8:39 PM, Andrew Dunstan wrote:
> OK, I've committed the YAML stuff, so who is working on the auto-explain
> bug? Robert? I'd like that fixed before I add in the query text to
> auto-explain output.
I'm going to propose fixing this in what seems to me to be the
simplest pos
Robert Haas wrote:
> On Thu, Dec 10, 2009 at 10:52 AM, Greg Smith wrote:
> >> I don't think IO is a terrible name for an option but I like BUFFERS
> >> better. ?I don't think the BUFFERS/BLOCKS confusion is too bad, but
> >> perhaps we could use BUFFERS in both places.
> >
> > I don't know how
Bruce Momjian wrote:
> Greg Smith wrote:
> > Bruce Momjian wrote:
> > > Peter Eisentraut wrote:
> > >
> > >>> if i remove the -j option then it runs without a problem
> > >>>
> > >> Possibly related to the incomplete removal of the enable-thread-safety
> > >> option that I just posted abo
Peter Eisentraut wrote:
> On tis, 2009-12-01 at 18:03 -0500, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Magnus Hagander writes:
> > > > 2009/12/1 Bruce Momjian :
> > > >> What are we going to do for build farm members who don't support
> > > >> threading? Is someone going to manually update th
On Thu, Dec 10, 2009 at 5:08 PM, Tom Lane wrote:
> If I thought that Bruce could go off in a corner and make this happen
> and it would create no demands on anybody but him and KaiGai-san, I
> would say "fine, if that's where you want to spend your time, go for
> it". But even to state that impli
Tom Lane wrote:
Greg Smith writes:
To be clear about which version we're talking about:
http://archives.postgresql.org/message-id/20091130123456.4a03.52131...@oss.ntt.co.jp
is the candidate for commit that includes the cleanup you've already done.
I suppose this is subject to the
Greg Smith wrote:
> Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> >
> >>> if i remove the -j option then it runs without a problem
> >>>
> >> Possibly related to the incomplete removal of the enable-thread-safety
> >> option that I just posted about.
> >>
> >
> > I thought about
Tom Lane wrote:
My guess is that a credible SEPostgres offering will require a long-term
amount of work at least equal to, and very possibly a good deal more
than, what it took to make a native Windows port.
Wow, if I thought that was the case I'd be as negative about the whole
thing as you ob
KaiGai Kohei wrote:
> > we still allow "SELECT * FROM pg_largeobject" ...right?
>
> It can be solved with revoking any privileges from anybody in the initdb
> phase. So, we should inject the following statement for setup_privileges().
>
> REVOKE ALL ON pg_largeobject FROM PUBLIC;
OK, I'll a
Bruce Momjian wrote:
Peter Eisentraut wrote:
if i remove the -j option then it runs without a problem
Possibly related to the incomplete removal of the enable-thread-safety
option that I just posted about.
I thought about that but I can't figure out how that would affect
pgbenc
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> > regression=# select
> > E'xxx\nxx\n'
> > as a, 1 as b;
> > a | b
> > --
Heiner Vega Thames escribió:
> Hi Guys
>
> I have some files that were part of a database, I mean they were
> under /*data/base/DB_OID/table_oid* postgres structure
>
> As I understand *table_oid *which is a numbered file corresponds to
> one table in the original database.
>
> Here is my questi
Peter Eisentraut wrote:
> > starting vacuum...end.
> > TRAP: FailedAssertion("!((data - start) == data_size)", File:
> > "heaptuple.c", Line: 255)
> > Client 0 aborted in state 8. Probably the backend died while processing.
> > LOG: server process (PID 30713) was terminated by signal 6: Aborted
>
Dimitri Fontaine wrote:
> Tom Lane writes:
> > It's not impossible that we'll have to tweak pg_dump a bit; it's
> > never had to deal with languages that shouldn't be dumped ...
>
> Ah, the best would be to have extensions maybe. Then you could do this
> in initdb, filling in template0:
> CREAT
Peter Eisentraut wrote:
On tor, 2009-12-10 at 17:20 -0500, Andrew Dunstan wrote:
Some time later it came up again, this time when someone wanted to use a
readonly database (hence no pg_dump required) with an application and
wanted to keep the database layout and the source code of stored
Hi Guys
I have some files that were part of a database, I mean they were under
/*data/base/DB_OID/table_oid* postgres structure
As I understand *table_oid *which is a numbered file corresponds to one
table in the original database.
Here is my question: Is there a tool/method to view the dat
On ons, 2009-12-09 at 16:23 -0500, Chris Browne wrote:
> This is a C front end for the LLVM compiler... I noticed that it
> entered Debian/Unstable today:
>
> http://packages.debian.org/sid/main/clang
>
> I thought it would be interesting to see if PostgreSQL compiles with
> this, as an altern
On tor, 2009-12-10 at 17:20 -0500, Andrew Dunstan wrote:
> Some time later it came up again, this time when someone wanted to use a
> readonly database (hence no pg_dump required) with an application and
> wanted to keep the database layout and the source code of stored
> functions hidden as the
On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote:
> There was considerable debate earlier about whether we wanted to treat
> Python 3 as a separate PL so it could be available in parallel with
> plpython 2, because of the user-level coding incompatibilities. It
> looks like this patch simply igno
"Kevin Grittner" writes:
> I'm inclined that it would be no more work to replace the current
> recursively called state engine with something easier to read and
> understand than to try to fix the current oddities. Perhaps
> something along the lines of this?:
> http://vo.astronet.ru/arxiv/dict
age...@themactionfaction.com ("A.M.") writes:
[Much of interest elided... Cool to see that clang clearly *can*
compile PostgreSQL...]
> You are probably running configure with gcc, no?
I was *attempting* to run configure using clang:
CC=/usr/bin/clang ./configure --prefix=/home/chris/dbs/pos
On ons, 2009-12-09 at 14:02 -0500, Jaime Casanova wrote:
> Hi,
>
> I compiled current HEAD and trying to use pgbench, i initialized a
> test database this way:
> bin/pgbench -i -F80 -s100 test
>
> and then run with this options:
> bin/pgbench -c 50 -j 5 -l -t 20 test
>
> and get this crash:
> ""
On tis, 2009-12-01 at 18:03 -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Magnus Hagander writes:
> > > 2009/12/1 Bruce Momjian :
> > >> What are we going to do for build farm members who don't support
> > >> threading? Is someone going to manually update their configure flags?
> >
> > > Yeah
We have a couple of lingering re-reviews that are still ongoing (myself
on "pgbench setshell" and the two DTrace ones), and the ECPG patches are
still hanging around, but we're basically finished with reviews for all
submitted patches at this point. So far 12 patches have been commited
since t
My two cents - if it's desired -
I invariably disable selinux from all of my production machines. Once
upon a time I tried to work with it time and time again - but it was
such a head ache to administer for what I considered to be marginal
gains, that I eventually gave up. Every time I add a s
It's funny; we started out this CommitFest with me scrambling to find
someone, anyone, willing to review the latest SE-PostgreSQL patch,
knowing it was a big job and few were likely to volunteer. Then
schedules lined up just right, and last night I managed to get a great
group of people all to
Hi,
On Thursday 10 December 2009 23:08:17 Tom Lane wrote:
> My guess is that a credible SEPostgres offering will require a long-term
> amount of work at least equal to, and very possibly a good deal more
> than, what it took to make a native Windows port. If SEPostgres could
> bring us even 10% a
On Thu, 2009-12-10 at 17:08 -0500, Tom Lane wrote:
> Robert Haas writes:
> > Unlike Tom (I think), I do believe that there is demand (possibly only
> > from a limited number of people, but demand all the same) for this
> > feature.
>
> Please note that I do not think there is *zero* demand for th
Tom Lane wrote:
Andrew Dunstan writes:
The other day I returned idly to thinking about some work I did a few
years ago on creating a totally unprivileged user, i.e. one with not
even public permissions.
And the point would be what exactly?
Well, when
Robert Haas writes:
> Unlike Tom (I think), I do believe that there is demand (possibly only
> from a limited number of people, but demand all the same) for this
> feature.
Please note that I do not think there is *zero* demand for the feature.
There is obviously some. What I find highly dubious
Hi -
On Thu, Dec 10, 2009 at 09:33:28PM +0100, Zdenek Kotala wrote:
> [...]
> > If the dormant overhead of these probes is measured or suspected to be
> > excessive, consider using the dtrace-generated per-probe foo_ENABLED()
> > conditional, or a postgres configuration global thusly:
> [...] fo
On Wed, Dec 9, 2009 at 10:43 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Wed, Dec 9, 2009 at 5:38 PM, Bruce Momjian wrote:
>> > If you want to avoid all good reasons for this features and are looking
>> > for reasons why this patch is a bad idea, I am sure you can find them.
>>
>> You see
re:
http://archives.postgresql.org/pgsql-hackers/2009-11/msg00754.php
Alvaro Herrera wrote:
> Kevin Grittner wrote:
>
>> (Note: I personally would much rather see the performance
>> penalty addressed this way, and a TODO added for the more
>> invasive work, than to leave this alone for the next
Jaime Casanova escribió:
> On Wed, Dec 9, 2009 at 9:39 AM, Tom Lane wrote:
> > so I'd like some independent confirmation that it does.
> >
>
> what kind of tests could show that? or simply running pgbench several
> times for 15 minutes each run could show any benefit?
Isn't the supposed performa
On tor, 2009-12-10 at 09:59 -0800, Josh Berkus wrote:
> Given that, we should have a --without-docs build switch which allows us
> to disable the doc build.
Btw., if you really, really, really want to avoid the issue (if there
were any), go into the src directory and build there.
--
Sent via pg
On Wed, Dec 9, 2009 at 9:39 AM, Tom Lane wrote:
> so I'd like some independent confirmation that it does.
>
what kind of tests could show that? or simply running pgbench several
times for 15 minutes each run could show any benefit?
--
Atentamente,
Jaime Casanova
Soporte y capacitación de Postgr
On tis, 2009-12-01 at 20:53 -0700, Joshua Tolley wrote:
> This patch doesn't include any documentation; my reading of the PL/Python docs
> suggests that's probably acceptable, as the existing docs don't talk about its
> array handling. That said, it might be useful to include an example, to show
>
Frank Ch. Eigler píše v čt 10. 12. 2009 v 14:11 -0500:
> Zdenek Kotala writes:
>
> > [...]
> > + header = (StandardChunkHeader *)
> > + ((char *) ret - STANDARDCHUNKHEADERSIZE);
> > +
> > +// TRACE_POSTGRESQL_MCXT_ALLOC(context->name, context, size, header->size,
> > true);
> > +
> >
Tom Lane wrote:
Andrew Dunstan writes:
If we really want to make linefeeds visible, I think we should place the
indicators immediately after the character preceding the line feed, not
next to the column separator.
Then it's hard to tell it apart from an instance of that character i
Andrew Dunstan writes:
> If we really want to make linefeeds visible, I think we should place the
> indicators immediately after the character preceding the line feed, not
> next to the column separator.
Then it's hard to tell it apart from an instance of that character in
the data.
Zdenek Kotala writes:
> [...]
> + header = (StandardChunkHeader *)
> + ((char *) ret - STANDARDCHUNKHEADERSIZE);
> +
> +// TRACE_POSTGRESQL_MCXT_ALLOC(context->name, context, size, header->size,
> true);
> +
> [...]
If the dormant overhead of these probes is measured or suspec
Tom Lane wrote:
> Josh Berkus writes:
> > On 12/10/09 10:03 AM, Tom Lane wrote:
> >> Josh Berkus writes:
> >>> Testing Alpha2 with the Exclusion Constraints patch on Mac recently
> >>> forced me to edit the makefiles to remove the make docs statements.
> >>
> >> How so? The make process does no
Andres Freund wrote:
> [concerns addressed in new patch version]
Looks good to me. I'm marking this Ready for Committer.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
regression=# select
E'xxx\nxx\n'
as a, 1 as b;
a | b
--+---
xxx
Ron Mayer wrote:
> Tom Lane wrote:
>> Why don't you
>> just do "\pset format unaligned" (or "\a" if you're lazy)?
>
> That's fair. Now that I see it, I guess I should have been
> doing that for copy&paste work anyway.
That'll cover my use cases.
-Kevin
--
Sent via pgsql-hackers mailing li
On Thursday 10 December 2009 19:10:24 Kevin Grittner wrote:
> I wrote:
> > Thanks for the sample which shows the difference.
>
> Ah, once I got on the right track, there is no problem seeing
> dramatic improvements with the patch. It changes some nasty O(N^2)
> cases to O(N). In particular, the
I wrote:
> I did find one significant (although easily solved) problem. In
> the patch, the recursive setup of usewide, pgwstr, and wstr are
> not conditioned by #ifdef USE_WIDE_UPPER_LOWER in the non-patched
> version. Unless there's a good reason for that, the #ifdef should
> be added.
That
--On 10. Dezember 2009 09:59:44 -0800 Josh Berkus wrote:
(The Mac Openjade toolchain is unalterably broken, AFAICT) Without
editing the makefiles, it wasn't possible to build PostgreSQL on my OSX
10.4 laptop.
You might get an idea how i fixed that here:
http://psoos.blogspot.com/2009/09/b
> Hm, maybe the alpha2 tarball had docs in it already? And they weren't
> up to date? You might be hitting the same thing I've complained of:
> since "make distclean" no longer removes built docs, you can find
> yourself running an update cycle when you didn't want to. Peter
> rejected my opini
Josh Berkus writes:
> On 12/10/09 10:03 AM, Tom Lane wrote:
>> Josh Berkus writes:
>>> Testing Alpha2 with the Exclusion Constraints patch on Mac recently
>>> forced me to edit the makefiles to remove the make docs statements.
>>
>> How so? The make process does not try to build the docs unless
Tom Lane wrote:
> Why don't you
> just do "\pset format unaligned" (or "\a" if you're lazy)?
That's fair. Now that I see it, I guess I should have been
doing that for copy&paste work anyway.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
On 12/10/09 10:03 AM, Tom Lane wrote:
> Josh Berkus writes:
>> Testing Alpha2 with the Exclusion Constraints patch on Mac recently
>> forced me to edit the makefiles to remove the make docs statements.
>
> How so? The make process does not try to build the docs unless you
> specifically tell it
Andrew Dunstan writes:
> Tom Lane wrote:
>> So you can tell a newline in the data from a wrap due to line length.
>> The need to be able to do that is not dependent on how many columns
>> there are.
> If that's really what we want then I think we're doing a terrible job of
> it. Have a look at t
Tom Lane wrote:
Andrew Dunstan writes:
I don't see much virtue of having these characters when there is only
one column.
So you can tell a newline in the data from a wrap due to line length.
The need to be able to do that is not dependent on how many columns
there are.
If that
I wrote:
> Thanks for the sample which shows the difference.
Ah, once I got on the right track, there is no problem seeing
dramatic improvements with the patch. It changes some nasty O(N^2)
cases to O(N). In particular, the fixes affect parsing of large
strings encoded with multi-byte charact
Josh Berkus writes:
> Testing Alpha2 with the Exclusion Constraints patch on Mac recently
> forced me to edit the makefiles to remove the make docs statements.
How so? The make process does not try to build the docs unless you
specifically tell it to.
> Given that, we should have a --without-do
Hackers,
Testing Alpha2 with the Exclusion Constraints patch on Mac recently
forced me to edit the makefiles to remove the make docs statements.
(The Mac Openjade toolchain is unalterably broken, AFAICT) Without
editing the makefiles, it wasn't possible to build PostgreSQL on my OSX
10.4 laptop.
On Thu, Dec 10, 2009 at 12:43 PM, Andrew Dunstan wrote:
> Tom Lane wrote:
>>
>> Andrew Dunstan writes:
>>
>>>
>>> Yeah, I'm thinking we should probably suppress output of format.nl_right
>>> (no matter what the format) where there is only one column. (This is even
>>> uglier with unicode linestyl
Andrew Dunstan writes:
> I don't see much virtue of having these characters when there is only
> one column.
So you can tell a newline in the data from a wrap due to line length.
The need to be able to do that is not dependent on how many columns
there are.
> And clearly I'm not the only person
Tom Lane wrote:
Andrew Dunstan writes:
Yeah, I'm thinking we should probably suppress output of format.nl_right
(no matter what the format) where there is only one column. (This is
even uglier with unicode linestyle, btw). That's a sane rule and it's
not an ugly hack.
Yes it is.
Andrew Dunstan writes:
> Yeah, I'm thinking we should probably suppress output of format.nl_right
> (no matter what the format) where there is only one column. (This is
> even uglier with unicode linestyle, btw). That's a sane rule and it's
> not an ugly hack.
Yes it is. The real problem here
Robert Haas wrote:
> Andrew Dunstan wrote:
>> A simple if ugly hack would make psql use old-ascii print style
>> (which doesn't use these contionuation chars) if the first
>> attribute in the resultset was named 'QUERY PLAN'
> I don't believe that machine-readable EXPLAIN output is the only
>
On Thu, Dec 10, 2009 at 11:44 AM, Ron Mayer
wrote:
> Alvaro Herrera wrote:
>> Robert Haas escribió:
>>> On first blush, I'm inclined to suggest that the addition of + signs
>>> to mark continuation lines is a misfeature.
>>
>> EXPLAIN is a special case. IMHO it should be dealt with accordingly.
>
Ron Mayer wrote:
Alvaro Herrera wrote:
Robert Haas escribió:
On first blush, I'm inclined to suggest that the addition of + signs
to mark continuation lines is a misfeature.
EXPLAIN is a special case. IMHO it should be dealt with accordingly.
Is it?
Wouldn't it affec
Andres Freund wrote:
> I think you see no real benefit, because your strings are rather
> short - the documents I scanned when noticing the issue where
> rather long.
The document I used in the test which showed the regression was
672,585 characters, containing 10,000 URLs.
> A rather extrem
Alvaro Herrera wrote:
> Robert Haas escribió:
>> On first blush, I'm inclined to suggest that the addition of + signs
>> to mark continuation lines is a misfeature.
>
> EXPLAIN is a special case. IMHO it should be dealt with accordingly.
>
Is it?
Wouldn't it affect anyone who stuck XML in a tx
--On 9. Dezember 2009 19:08:07 -0500 Theo Schlossnagle
wrote:
Now, there was some indication that there was a better place to probe
that would be more comprehensive -- that should be addressed.
For now there exists no consensus where they should go in. Tom pointed out
various issues with
Robert Haas escreveu:
> The only reason anyone is even thinking that they need parentheses
> here is because they're trying to put three separate groups of
> buffer-related statistics - a total of 8 values - on the same output
> line. If this were split up over three output lines, no one would
> e
On Thu, Dec 10, 2009 at 10:50 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Dec 10, 2009 at 9:03 AM, Euler Taveira de Oliveira
>> wrote:
>>> Why? If you want this information for all of your queries, you can always
>>> set
>>> auto_explain.log_min_duration to 0. But if you're suggesting
On Thu, Dec 10, 2009 at 10:52 AM, Greg Smith wrote:
> Robert Haas wrote:
>>
>> I don't think IO is a terrible name for an option but I like BUFFERS
>> better. I don't think the BUFFERS/BLOCKS confusion is too bad, but
>> perhaps we could use BUFFERS in both places.
>
> I don't know how "blocks" g
Robert Haas wrote:
I don't think IO is a terrible name for an option but I like BUFFERS
better. I don't think the BUFFERS/BLOCKS confusion is too bad, but
perhaps we could use BUFFERS in both places.
I don't know how "blocks" got into here in the first place--this concept
is "buffers" just a
Robert Haas writes:
> On Thu, Dec 10, 2009 at 9:03 AM, Euler Taveira de Oliveira
> wrote:
>> Why? If you want this information for all of your queries, you can always set
>> auto_explain.log_min_duration to 0. But if you're suggesting that we should
>> maintain log_statement_stats (that was not I
1 - 100 of 117 matches
Mail list logo
