Hi,
> But if it's deemed to be a
> problem, I want to see a solution that's actually watertight.)
>
>
After Daniel's hunch about pg_dump barfing due to such leftover entries
proving out to be true, we have one credible explanation (there might be
other reasons too) for this long standing issue. I
On 11 Listopad 2011, 3:23, Euler Taveira de Oliveira wrote:
> On 10-11-2011 21:12, Tomas Vondra wrote:
>> I occasionally need to perform some action whenever a user connects, and
>> there's nothing like an "AFTER LOGON" trigger (available in some other
>> databases).
>>
> Are you proposing an on-lo
On Nov 10, 2011, at 9:45 PM, Itagaki Takahiro wrote:
>> Parser error?
>
> You need double-quotes around the name:
> =# CREATE EXTENSION "uuid-ossp";
> CREATE EXTENSION
Ah! Okay, thank you!
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
> > Continuing in gdb, also completes the creation of c2 table without any
> > errors. We are now left with a dangling entry in pg_class along with all
> the
> > corresponding data files in our data directory. The problem becomes
> worse if
> > c2 was created using a TABLESPACE. Now dropping of tha
On Fri, Nov 11, 2011 at 14:40, David E. Wheeler wrote:
> one might use "-" in the name itself, but probably not "--" -- it seems that
> the dash is not actually allowed:
>
> create extension pgtap-core;
> ERROR: syntax error at or near "-"
> LINE 1: create extension pgtap-core;
>
> Pars
Hackers,
So after Tom made "--" the separator between an extension name and the version
information in extension file names -- because one might use "-" in the name
itself, but probably not "--" -- it seems that the dash is not actually allowed:
create extension pgtap-core;
ERROR: synt
Hackers,
I’m preparing a new release of pgTAP, and have started breaking it down into
smaller extensions. I’ve been planning to have them all in one distribution
file for now, but it seems that one cannot specify multiple extension names in
the EXTENSION variable. In my Makefile, I have
EX
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Nov 10, 2011 at 10:52 PM, Stephen Frost wrote:
> > Certainly a big one that people get caught by is our default of execute
> > to public on functions.. Most of our privileges are set up as minimal
> > access to others, functions are an oddity
On Wed, Nov 9, 2011 at 1:56 AM, Nikhil Sontakke wrote:
> Hi,
>
> Consider the following sequence of events:
>
> s1 #> CREATE SCHEMA test_schema;
>
> s1 #> CREATE TABLE test_schema.c1(x int);
>
> Now open another session s2 and via gdb issue a breakpoint on
> heap_create_with_catalog() which is cal
On Thu, Nov 10, 2011 at 10:52 PM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Stephen Frost writes:
>> > A LOT of catalog bulk..? Am I missing something here?
>>
>> What I'm missing is what actual benefit we get from spending the extra
>> space. (No, I don't believe that ch
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > A LOT of catalog bulk..? Am I missing something here?
>
> What I'm missing is what actual benefit we get from spending the extra
> space. (No, I don't believe that changing the defaults is something
> that users commonly will or
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> To actually get rid of acldefault, we'd have to do that not only for
>> types but for all objects with ACLs. That's a LOT of catalog bulk,
>> and like Robert I'm not seeing much benefit. It's not unreasonable
>> to want the typica
Excerpts from Thom Brown's message of jue nov 10 21:28:06 -0300 2011:
>
> On 10 November 2011 23:56, Thom Brown wrote:
> > The dump correctly contains:
> >
> > CREATE TABLE a (
> > num integer,
> > CONSTRAINT meow CHECK ((num < 20)) NOT VALID
> > );
>
> Actually I mean incorrectly contai
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Thu, Nov 10, 2011 at 3:17 PM, Peter Eisentraut wrote:
> >> No, I'm pondering having pg_default_acl initialized so that newly
> >> created types have explicit USAGE privileges in their typacl column, so
> >> acldefault() wouldn't
On Thu, Nov 10, 2011 at 1:19 PM, Dimitri Fontaine
wrote:
> Now the aim would be to be able to implement the operation you describe
> by using the new segment map, which is an index pointing to sequential
> ranges of on-disk blocks where the data is known to share a common key
> range over the colu
Robert Haas writes:
> ... What I think it's mostly doing at this point is making it
> more difficult to make further changes - you do whatever you want to
> do, and then you have to go figure out what to do about the crazy
> LOCK_DEBUG stuff that no one uses.
[ shrug... ] If you're sufficiently
On 10-11-2011 21:12, Tomas Vondra wrote:
> I occasionally need to perform some action whenever a user connects, and
> there's nothing like an "AFTER LOGON" trigger (available in some other
> databases).
>
Are you proposing an on-logon hook or an on-connect trigger? It is two
separate things. The f
On Thu, Nov 10, 2011 at 5:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> It's possible to compile the source tree with LOCK_DEBUG defined, but
>> the resulting postgres promptly dumps core, due to the fact that
>> user_lockmethod doesn't supply any value for trace_flag; thus, the
>> first LockRe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10-11-2011 21:42, Josh Kupershmidt wrote:
> On Thu, Nov 10, 2011 at 3:41 PM, Bruce Momjian wrote:
>> Have you tried \d+ with this psql mode:
>>
>>\pset format wrapped
>>
>> It wraps the data so it fits on the screen --- it is my default in
On 10 November 2011 23:56, Thom Brown wrote:
> On 18 July 2011 02:46, Alvaro Herrera wrote:
>> Excerpts from Robert Haas's message of dom jul 17 20:36:49 -0400 2011:
>>
>>> > Does git allow for additional commit fields? That would allow for easy
>>> > tracking without much additional burden on c
On Thu, Nov 10, 2011 at 6:12 PM, Tom Lane wrote:
>> As I suggested, many more unexpected failures (e.g. \dnS+) pop up when
>> talking to a 7.3 server. It's not a big deal, but it'd be nice if we
>> could instead error out with a "sorry, we're too lazy to try to
>> support 7.3" on the meta-commands
On 18 July 2011 02:46, Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of dom jul 17 20:36:49 -0400 2011:
>
>> > Does git allow for additional commit fields? That would allow for easy
>> > tracking without much additional burden on committers.
>>
>> I mean, there's git notes, but that
On Tue, Nov 08, 2011 at 06:36:52AM +0200, Peter Eisentraut wrote:
> Here is an updated patch that addresses all the issues you pointed out.
Looks ready to me. Thanks.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
Andrew Dunstan writes:
> On 11/10/2011 04:59 PM, Tom Lane wrote:
>> Nonetheless, it's solving the wrong problem. Any program that is being
>> written today to read EXPLAIN output should be written to read one of
>> the machine-readable formats.
> Umm, it *does* handle all the formats:
The point
On Thu, Nov 10, 2011 at 3:41 PM, Bruce Momjian wrote:
> Have you tried \d+ with this psql mode:
>
> \pset format wrapped
>
> It wraps the data so it fits on the screen --- it is my default in my
> .psqlrc.
I think that's one of the many psql features I haven't experimented
with, thanks for
On 11/10/2011 05:26 PM, Greg Smith wrote:
I know some of the earlier versions of XML EXPLAIN included a "DTD"
option to output that, but I don't see that in the committed code.
I'm not sure where that is at actually; it's a good question.
The only reference to doing this I found was Andre
On 11/10/2011 04:59 PM, Tom Lane wrote:
Andrew Dunstan writes:
Pg--Explain is extremely well written, and should be easily translatable
to Java if you really need to. The whole thing is less than 2000 lines,
and a large part of that is comments.
Nonetheless, it's solving the wrong problem.
Hi,
I occasionally need to perform some action whenever a user connects, and
there's nothing like an "AFTER LOGON" trigger (available in some other
databases).
Is there any particular reason why there's not a "backend start hook",
executed right after a backend is initialized? I've tried a very s
Josh Kupershmidt writes:
> FWIW, I just played around with 7.4 and 7.3 servers. (I had some bad
> memories of the older tarballs not building, but that must have been
> only on OS X -- I can build at least back to 7.3 on this Ubuntu 11.04
> machine.)
> Most meta-commands worked alright on 7.4, or
On Thu, Nov 10, 2011 at 5:07 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Robert Haas writes:
>> > It's possible to compile the source tree with LOCK_DEBUG defined, but
>> > the resulting postgres promptly dumps core, due to the fact that
>> > user_lockmethod doesn't supply any value for trace_f
On 2011-11-10 23:42, Andreas Karlsson wrote:
Hi,
I recommend using the XML, JSON or YAML version of the plan, whichever
is easiest in your programming language to parse. I do not think anyone
has written a formal schema yet for the XML but it still should be much
easier to parse than rolling you
Bruce Momjian writes:
> Tom Lane wrote:
>> Huh? You put it in the connection string, typically. This is not
>> different from how you'd specify sslmode to start with.
> Well, you are saying the client is more flexible, but if the client is a
> binary, it isn't flexible without an environment va
On 2011-11-10 17:23, Αναστάσιος Αρβανίτης wrote:
Also another option I am considering is to use EXPLAIN [query] FORMAT XML which
is available in PostgreSQL 9.1. However, in that case it
would better to have the XML Schema of the generated plans available.
Is there any other solution I am not aw
Tom Lane wrote:
> Bruce Momjian writes:
> > How is the compression connection parameter set? It seems odd for it to
> > be compiled into the application because the application could be run on
> > different networks. I don't know of any way to inject connection
> > options from outside the appli
On 11/10/2011 11:10 AM, Αναστάσιος Αρβανίτης wrote:
I'm developing an application that requires parsing of
execution plans (those produced as output by issuing an EXPLAIN [query]
command). Are you aware of any Java library that I could use for this
purpose? I found https://github.com/depesz/Pg--E
Bruce Momjian writes:
> How is the compression connection parameter set? It seems odd for it to
> be compiled into the application because the application could be run on
> different networks. I don't know of any way to inject connection
> options from outside the application like libpq's PGOPTI
Robert Haas writes:
> On Thu, Nov 10, 2011 at 3:17 PM, Peter Eisentraut wrote:
>> No, I'm pondering having pg_default_acl initialized so that newly
>> created types have explicit USAGE privileges in their typacl column, so
>> acldefault() wouldn't be needed. (And builtin types would have their
>
Tom Lane wrote:
> Robert Haas writes:
> > It's possible to compile the source tree with LOCK_DEBUG defined, but
> > the resulting postgres promptly dumps core, due to the fact that
> > user_lockmethod doesn't supply any value for trace_flag; thus, the
> > first LockReleaseAll(USER_LOCKMETHOD) dere
Robert Haas wrote:
> Now, whether or not this facility is well designed is a worthwhile
> question. Trace_lock_oidmin seems pretty sketchy to me, especially
> because it's blindly applied to even to lock tags where the second
> field isn't a relation - i.e. SET_LOCKTAG_TRANSACTION sets it to zero,
Robert Haas writes:
> It's possible to compile the source tree with LOCK_DEBUG defined, but
> the resulting postgres promptly dumps core, due to the fact that
> user_lockmethod doesn't supply any value for trace_flag; thus, the
> first LockReleaseAll(USER_LOCKMETHOD) dereferences a NULL pointer.
>
Andrew Dunstan writes:
> On 11/10/2011 04:29 PM, Robert Haas wrote:
>> 2011/11/10 ÁíáóôÜóéïò Áñâáíßôçò:
>>> Is there any other solution I am not aware of?
>> Not that I know of. I think pgAdmin can parse the EXPLAIN output,
>> too, but that's in C++.
> Pg--Explain is extremely well written, and
Bruce Momjian wrote:
>> No, version 2 of the patch used the strchr() technique and has
>> *zero* new functions and *zero* new macros.
>
> Right. I was referring to the non-strchr() approach in the
> initial patch.
I'm sorry that I misunderstood you.
So, I don't think I've heard any argumen
Tom Lane wrote:
> "Albe Laurenz" writes:
> > Tom Lane wrote:
> >> A GUC is entirely, completely, 100% the wrong answer. It has no way
> >> to deal with the fact that some clients may need compression and others
> >> not.
>
> > You can force a certain SSL cipher on the client, why not a compressi
On 11/10/2011 04:29 PM, Robert Haas wrote:
2011/11/10 Αναστάσιος Αρβανίτης:
I'm developing an application that requires parsing of
execution plans (those produced as output by issuing an EXPLAIN [query]
command). Are you aware of any Java library that I could use for this
purpose? I found http
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > I realize the patch only added 1-2 new const functions
>
> No, version 2 of the patch used the strchr() technique and has
> *zero* new functions and *zero* new macros.
Right. I was referring to the non-strchr() approach in the initial
patch.
Bruce Momjian wrote:
> I realize the patch only added 1-2 new const functions
No, version 2 of the patch used the strchr() technique and has
*zero* new functions and *zero* new macros.
> but this is only a small area of the code being patched --- a full
> solution would have many more comple
2011/11/10 Αναστάσιος Αρβανίτης :
> I'm developing an application that requires parsing of
> execution plans (those produced as output by issuing an EXPLAIN [query]
> command). Are you aware of any Java library that I could use for this
> purpose? I found https://github.com/depesz/Pg--Explain but i
On Thu, Nov 10, 2011 at 3:17 PM, Peter Eisentraut wrote:
> On ons, 2011-11-09 at 00:21 -0500, Tom Lane wrote:
>> Peter Eisentraut writes:
>> > Let me put this differently. Should we either continue to hardcode the
>> > default privileges in the acldefault() function, or should we instead
>> > in
It's possible to compile the source tree with LOCK_DEBUG defined, but
the resulting postgres promptly dumps core, due to the fact that
user_lockmethod doesn't supply any value for trace_flag; thus, the
first LockReleaseAll(USER_LOCKMETHOD) dereferences a NULL pointer.
This is the result of the foll
Alvaro Herrera wrote:
>
> Excerpts from Bruce Momjian's message of jue nov 10 16:59:20 -0300 2011:
> > Alvaro Herrera wrote:
> > > Hello,
> > >
> > > After some rather extensive rewriting, I submit the patch to improve
> > > foreign key locks.
> > >
> > > To recap, the point of this patch is to
Jeff Janes writes:
> shouldn't it need a DBA to declare it? How is the system supposed to
> anticipate that at some point years in the future I will want to run
> the command sequence "create foo_archive as select from foo where
> year<2009; delete from foo where year<2009", or its partition-base
Bruce Momjian writes:
> Tom Lane wrote:
>> However, the bigger picture is that OS X's UTF8 locales are broken
>> through-and-through, and most of their other problems are not feasible
>> to work around.
> If Apple's low-level code came from FreeBSD and NetBSD, how did they get
> so broken?
AFAIK
Tom Lane wrote:
> J Smith writes:
> > I've attached a patch against master for unaccent.c that uses swscanf
> > along with char2wchar and wchar2char instead of sscanf directly to
> > initialize the unaccent extension and it appears to fix the problem in
> > both the master and 9.1 branches.
>
> s
Kevin Grittner wrote:
> Tom Lane wrote:
>
> > The problem with it of course is that mistaken use could have the
> > effect of casting-away-const, which is exactly what we hoped to
> > prevent. Still, there may not be a better solution.
>
> Yeah, I've come to the conclusion that the compiler d
Excerpts from Bruce Momjian's message of jue nov 10 16:59:20 -0300 2011:
> Alvaro Herrera wrote:
> > Hello,
> >
> > After some rather extensive rewriting, I submit the patch to improve
> > foreign key locks.
> >
> > To recap, the point of this patch is to introduce a new lock tuple mode,
> > tha
Robert Haas wrote:
> On Sun, Nov 6, 2011 at 3:29 PM, Josh Kupershmidt wrote:
> > On Sun, Nov 6, 2011 at 1:16 PM, Dickson S. Guedes
> > wrote:
> >>> test=# \d+ foo
> >>> ? ? ? ? ? ? ? ? ? ? ? ? Table "public.foo"
> >>> ?Column | ?Type ? | Storage
> >>> +-+-
> >>> ?a ? ? ?|
On Thu, Nov 10, 2011 at 3:29 PM, Kevin Grittner
wrote:
> Christopher Browne wrote:
>
>> There's value in having an "immutability" constraint on a column,
>> where, in effect, you're not allowed to modify the value of the
>> column, once assigned.
>
> +1 We would definitely use such a feature, sh
Christopher Browne wrote:
> There's value in having an "immutability" constraint on a column,
> where, in effect, you're not allowed to modify the value of the
> column, once assigned.
+1 We would definitely use such a feature, should it become
available.
-Kevin
--
Sent via pgsql-hackers
Tom Lane wrote:
> The problem with it of course is that mistaken use could have the
> effect of casting-away-const, which is exactly what we hoped to
> prevent. Still, there may not be a better solution.
Yeah, I've come to the conclusion that the compiler doesn't do the
apparently-available o
Peter Eisentraut wrote:
> On m?n, 2011-09-19 at 07:06 +0300, Peter Eisentraut wrote:
> > I found a simpler way to get this working. Just hack up the catalogs
> > for the new path directly. So I can now run this test suite against
> > older versions as well, like this:
> >
> > contrib/pg_upgrade$
2011/11/10 Christopher Browne :
> On Sun, Nov 6, 2011 at 2:28 AM, Jeroen Vermeulen wrote:
>> On 2011-11-04 01:12, Alvaro Herrera wrote:
>>
>>> I would like some opinions on the ideas on this patch, and on the patch
>>> itself. If someone wants more discussion on implementation details of
>>> each
On Sun, Nov 6, 2011 at 2:28 AM, Jeroen Vermeulen wrote:
> On 2011-11-04 01:12, Alvaro Herrera wrote:
>
>> I would like some opinions on the ideas on this patch, and on the patch
>> itself. If someone wants more discussion on implementation details of
>> each part of the patch, I'm happy to provid
On ons, 2011-11-09 at 00:21 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > Let me put this differently. Should we either continue to hardcode the
> > default privileges in the acldefault() function, or should we instead
> > initialize the system catalogs with an entry in pg_default_acl as
On tis, 2011-11-08 at 16:08 -0500, Andrew Dunstan wrote:
>
> On 03/01/2011 11:50 AM, Peter Eisentraut wrote:
> > On fre, 2011-02-11 at 16:49 +0100, Jan Urbański wrote:
> >> I believe it's (b). But as we don't have time for that discussion that
> >> late in the release cycle, I think we need to con
"Kevin Grittner" writes:
> Tom mentioned the strchr() function, which does do that. I don't
> actually find that surprising given my understanding of the
> semantics. That means that the function is promising not to modify
> the character array, but is not asserting that it knows the
> character
Steve Singer writes:
> On 11-11-10 02:00 PM, Tom Lane wrote:
>> ... Oh, I see, the problem is that&labels[-1] might not compare to
>> &labels[0] the way we want. I think only the first hunk of your
>> patch is actually necessary.
> Yes the problem is still fixed if I only apply the first hunk.
Peter Eisentraut writes:
> On ons, 2011-11-09 at 10:49 -0500, Tom Lane wrote:
>> Now admittedly you can hack it, in the same
>> spirit as the C library functions that are declared to take const
>> pointers and return non-const pointers to the very same data
> Which C library functions do that?
Alvaro Herrera wrote:
> Hello,
>
> After some rather extensive rewriting, I submit the patch to improve
> foreign key locks.
>
> To recap, the point of this patch is to introduce a new lock tuple mode,
> that lets the RI code obtain a lighter lock on tuples, which doesn't
> conflict with updates
Peter Eisentraut wrote:
> On ons, 2011-11-09 at 10:49 -0500, Tom Lane wrote:
>> Now admittedly you can hack it, in the same
>> spirit as the C library functions that are declared to take const
>> pointers and return non-const pointers to the very same data
>
> Which C library functions do that?
On mån, 2011-11-07 at 10:07 -0500, Tom Lane wrote:
> >> 2. Macros accessing structures should come in two variants: a
> "get"
> >> version, and a "set"/anything else version, so that the "get"
> version
> >> can preserve the const qualifier.
>
> I'm not prepared to buy into that as a general codi
On 11-11-10 02:00 PM, Tom Lane wrote:
Steve Singer writes:
The man page for malloc on AIX is pretty clear on what happens when you
try to malloc 0 bytes. It returns NULL.
Yes, that's a pretty common behavior for malloc(0). It should not cause
a problem here AFAICS.
... Oh, I see, the probl
On ons, 2011-11-09 at 10:49 -0500, Tom Lane wrote:
> Now admittedly you can hack it, in the same
> spirit as the C library functions that are declared to take const
> pointers and return non-const pointers to the very same data
Which C library functions do that?
--
Sent via pgsql-hackers maili
Bruce Momjian writes:
> Well, we could use an optional "details" string for that. If not, we
> are still using the magic-string approach, which I thought we didn't
> like.
No, we're not using magic strings, we're using an enum --- maybe not an
officially declared enum type, but it's a column wit
Florian Pflug wrote:
> On Nov9, 2011, at 22:54 , Kevin Grittner wrote:
>> Tom Lane wrote:
>>
>>> I don't doubt that just duplicating macros and inlineable
>>> functions is a wash performance-wise (in fact, in principle it
>>> shouldn't change the generated code at all).
>>
>> I had the impressi
Brar Piening wrote:
>
> Josh Berkus wrote:
> > Hackers,
> >
> > Is there a reason why INTERVAL 'infinity' is not implemented? That is,
> > an interval which is larger than all defined intervals, and which added
> > to any timestamp turns it into 'infinity'.
> >
> > Or is it just Round TUITs?
>
>
Tom Lane wrote:
> Bruce Momjian writes:
> > It might be cleaner to use booleans:
> > active: t/f
> > in transaction: t/f
>
> I don't think so, because that makes some very strict assumptions that
> there are exactly four interesting states (an assumption that isn't
> even true tod
Bruce Momjian writes:
> It might be cleaner to use booleans:
> active: t/f
> in transaction: t/f
I don't think so, because that makes some very strict assumptions that
there are exactly four interesting states (an assumption that isn't
even true today, to judge by the activity
Steve Singer writes:
> The man page for malloc on AIX is pretty clear on what happens when you
> try to malloc 0 bytes. It returns NULL.
Yes, that's a pretty common behavior for malloc(0). It should not cause
a problem here AFAICS.
... Oh, I see, the problem is that &labels[-1] might not comp
Scott Mead wrote:
> On Wed, Nov 2, 2011 at 4:12 AM, Albe Laurenz wrote:
>
> > Andrew Dunstan wrote:
> > > On 11/01/2011 09:52 AM, Tom Lane wrote:
> > >> I'm for just redefining the query field as "current or last
> > >> query".
> > >
> > > +1
> > >
> > >> I could go either way on whether to rename
On Nov 5, 2011 9:02 AM, "Greg Smith" wrote:
>
> On 11/04/2011 05:01 PM, Tom Lane wrote:
>>
>> Scott Mead writes:
>>
>>>
>>>I leave the waiting flag in place for posterity. With this in mind,
is
>>> the consensus:
>>>RUNNING
>>> or
>>>ACTIVE
>>>
>>
>> Personally, I'd go for lower
On 11-11-09 06:35 PM, Tom Lane wrote:
Steve Singer writes:
I've tracked the issue down to collectSecLabels in pg_dump.c
SELECT label, provider, classoid, objoid, objsbid FROM
pg_catalog.pg_seclabel;
returns 0 rows.
The code in collectSecLabels() is not prepared to deal with a zero row
Robert Haas wrote:
> On Thu, Nov 3, 2011 at 3:45 PM, Kevin Grittner
> wrote:
> > "Kevin Grittner" wrote:
> >> Untested patch attached for purposes of discussion.
> >
> > I got in a little testing on it -- not only does this patch
> > eliminate the compile-time warning, but if you try to run pg_up
> Um ... why would we do this only for tables, and not for creations of
> other sorts of objects that belong to schemas?
>
>
Right, we need to do it for other objects like functions etc. too.
> Also, if we are going to believe that this is a serious problem, what
> of ALTER ... SET SCHEMA?
>
>
I
I'm developing an application that requires parsing of
execution plans (those produced as output by issuing an EXPLAIN [query]
command). Are you aware of any Java library that I could use for this
purpose? I found https://github.com/depesz/Pg--Explain but it is built in Perl.
Also another opt
On Thu, Nov 10, 2011 at 5:18 PM, Albe Laurenz wrote:
> I could go and try to convince Npgsql and JDBC to accept patches to
> do that on the client side, but that would be more effort than I
> want to invest. But then there's still closed source software like
> Devart dotConnect...
Are you certai
I'm developing an application that requires parsing of
execution plans (those produced as output by issuing an EXPLAIN [query]
command). Are you aware of any Java library that I could use for this
purpose? I found https://github.com/depesz/Pg--Explain but it is built in Perl.
Also another opt
On Thu, Nov 10, 2011 at 11:01 AM, Tom Lane wrote:
> But in any case, my objection is that there's no adequate use-case
> for this GUC, because it's much more sensible to set it from the client
> side. We have too many GUCs already --- Josh B regularly goes on the
> warpath looking for ones we can
"Albe Laurenz" writes:
> Tom Lane wrote:
>> A GUC is entirely, completely, 100% the wrong answer. It has no way
>> to deal with the fact that some clients may need compression and others
>> not.
> You can force a certain SSL cipher on the client, why not a compression
> setting?
To my mind, the
On 11/10/11 16:05, Tom Lane wrote:
> I agree with Jan that this is probably useful; I'm pretty sure there
> have been requests for it before. We just have to make sure that the
> length of the message stays in bounds.
>
> One tip for keeping the length down: there is no value in repeating
> infor
Robert Haas writes:
> On Thu, Nov 10, 2011 at 10:05 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> Well, if we're going to try to emit some context here, I'd suggest
>>> that we try to output only the columns implicated in the CHECK
>>> constraint, rather than the whole tuple.
>> I think that's
Nikhil Sontakke writes:
> PFA, a patch against git head. We take the AccessShareLock lock on the
> schema in DefineRelation now.
Um ... why would we do this only for tables, and not for creations of
other sorts of objects that belong to schemas?
Also, if we are going to believe that this is a se
do you have more documentation about OPENMP and PostgreSQL?
El 09-11-2011 20:12, Greg Smith escribió:
On 11/09/2011 04:10 PM, Rudyar Cortés wrote:
I'm a new programmer in postgreSQL source code..
Is possible use MPI functions in postgreSQL source code?
To do this the proper way, you woul
On Thu, Nov 10, 2011 at 10:05 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Nov 10, 2011 at 5:40 AM, Jan Kundrát wrote:
>>> Would you object to a patch which outputs just the first 8kB of each
>>> column? Having at least some form of context is very useful in my case.
>
>> Well, if we're
Tom Lane wrote:
>>> Is the following proposal acceptable:
>>>
>>> - Add a GUC ssl_compression, defaulting to "on".
>>> - Add a client option "sslcompression" and an environment variable
>>> PGSSLCOMPRESSION, defaulting to "1".
> A GUC is entirely, completely, 100% the wrong answer. It has no way
On Thursday, November 10, 2011, Andrew Dunstan wrote:
>
>
> On 11/08/2011 12:39 PM, Tom Lane wrote:
>
>> Jeroen Vermeulen writes:
>>
>>> Another reason why I believe compression is often used with encryption
>>> is to maximize information content per byte of data: harder to guess,
>>> harder to c
Robert Haas writes:
> On Thu, Nov 10, 2011 at 5:40 AM, Jan Kundrát wrote:
>> Would you object to a patch which outputs just the first 8kB of each
>> column? Having at least some form of context is very useful in my case.
> Well, if we're going to try to emit some context here, I'd suggest
> that
"""
What I want to find in the end is something which tells me "this row
causes the error". Unfortunately, as the new row of the table with the
constraint is not yet on disk, it doesn't really have its own ctid, and
therefore I cannot report that. (Which makes sense, obviously.)
"""
Would an erro
On 11/08/2011 12:39 PM, Tom Lane wrote:
Jeroen Vermeulen writes:
Another reason why I believe compression is often used with encryption
is to maximize information content per byte of data: harder to guess,
harder to crack. Would that matter?
Yes, it would. There's a reason why the OpenSSL
On 11/10/11 13:04, Robert Haas wrote:
> Well, if we're going to try to emit some context here, I'd suggest
> that we try to output only the columns implicated in the CHECK
> constraint, rather than the whole tuple. I'm not sure whether
> emitting only a certain amount of output (either total, or f
On Thu, Nov 10, 2011 at 5:40 AM, Jan Kundrát wrote:
> That's an interesting thought. I suppose the same thing is an issue with
> unique keys, but they tend to not be created over huge columns, so it
> isn't really a problem, right?
Pretty much.
> Would you object to a patch which outputs just th
1 - 100 of 106 matches
Mail list logo
