Robert Haas wrote:
>On Fri, Jul 22, 2011 at 12:32 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Fri, Jul 22, 2011 at 12:13 PM, Tom Lane wrote:
Well, if you read it that way, then CREATE USER MAPPING with an empty
option set is a no-op: the behavior of the FDW would be the same whet
On Saturday, July 23, 2011, Christopher Browne wrote:
> I generally agree, Josh, but I think readline is getting pointed at a bit too
> much. Yeah, it's a bad one, but we also include other stuff like zlib that
> doesn't commonly come up as an issue.
> I'd argue something just a wee bit differe
On Fri, Jul 22, 2011 at 7:12 PM, Robert Haas wrote:
> Hmm. That's tricky. I lean mildly toward throwing an error as being
> more consistent with the general PG philosophy.
I agree. Besides, throwing an error on duplicate keys seems like the
most logical thing to do. The most compelling reason
On 07/22/2011 08:15 PM, David Fetter wrote:
Do you have any theories as to how indexing on SSD speeds things up?
IIRC you found only marginal benefit in putting WALs there. Are there
cases that SSD helps more than others when it comes to indexing?
Yes, I've found a variety of workloads whe
I generally agree, Josh, but I think readline is getting pointed at a bit
too much. Yeah, it's a bad one, but we also include other stuff like zlib
that doesn't commonly come up as an issue.
I'd argue something just a wee bit different...
By the time we would add in:
- autoconf rules to detect
On Jul23, 2011, at 00:04 , Joey Adams wrote:
> I think I've decided to only allow escapes of non-ASCII characters
> when the database encoding is UTF8. For example, $$"\u2013"$$::json
> will fail if the database encoding is WIN1252, even though WIN1252 can
> encode U+2013 (EN DASH). This may be s
On Fri, Jul 22, 2011 at 05:15:37PM -0400, Greg Smith wrote:
> That looks straightforward enough. The other thing I keep realizing
> would be useful recently is to allow specifying a different
> tablespace to switch to when creating all of the indexes. The old
> "data here, indexes on faster stora
On Jul23, 2011, at 01:12 , Robert Haas wrote:
> On Fri, Jul 22, 2011 at 6:04 PM, Joey Adams
> wrote:
>> On another matter, should the JSON type guard against duplicate member
>> keys? The JSON RFC says "The names within an object SHOULD be
>> unique," meaning JSON with duplicate members can be c
Arguments in favor of coding from scratch:
1) Does not introduce new dependencies into postgresql-client packages.
(note how much of a problem Readline has been)
2) keeps psql as lightweight as possible
3) We don't need to be able to parse any potential URI, just the ones we
accept.
Arguments a
On Fri, Jul 22, 2011 at 7:16 PM, Jan Urbański wrote:
> On 23/07/11 01:12, Robert Haas wrote:
>> On Fri, Jul 22, 2011 at 6:04 PM, Joey Adams
>> wrote:
>>> On another matter, should the JSON type guard against duplicate member
>>> keys? The JSON RFC says "The names within an object SHOULD be
>>>
On 23/07/11 01:12, Robert Haas wrote:
> On Fri, Jul 22, 2011 at 6:04 PM, Joey Adams
> wrote:
>> On another matter, should the JSON type guard against duplicate member
>> keys? The JSON RFC says "The names within an object SHOULD be
>> unique," meaning JSON with duplicate members can be considere
On Fri, Jul 22, 2011 at 6:04 PM, Joey Adams wrote:
> On another matter, should the JSON type guard against duplicate member
> keys? The JSON RFC says "The names within an object SHOULD be
> unique," meaning JSON with duplicate members can be considered valid.
> JavaScript interpreters (the ones I
I think I've decided to only allow escapes of non-ASCII characters
when the database encoding is UTF8. For example, $$"\u2013"$$::json
will fail if the database encoding is WIN1252, even though WIN1252 can
encode U+2013 (EN DASH). This may be somewhat draconian, given that:
* SQL_ASCII can othe
Jim,
> Arguably, we could just create an add-on data type for storing that timezone
> information, but that seems pretty daft to me: you're stuck either storing
> raw text which takes what should be a 12 byte datatype up to a 20-30 byte
> type (8 byte timestamp + varlena + text of timezone name
"Kevin Grittner" wrote:
> I believe that we can get DELETE behavior which is every bit as
> sensible as INSERT behavior with a very small change.
> I think the right thing is to throw an error if the old row for a
> BEFORE UPDATE is updated by the same transaction and the trigger
> function ul
On Fri, Jul 22, 2011 at 4:39 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of vie jul 22 12:14:30 -0400 2011:
>> On Thu, Jul 21, 2011 at 7:51 PM, Alvaro Herrera
>> wrote:
>> >> I think that there probably ought to be a way to display the NOT NULL
>> >> constraint names (perhaps
That looks straightforward enough. The other thing I keep realizing
would be useful recently is to allow specifying a different tablespace
to switch to when creating all of the indexes. The old "data here,
indexes on faster storage here" trick was already popular in some
environments. But it
Robert Haas wrote:
> On Wed, Jul 20, 2011 at 2:58 PM, Kevin Grittner
> wrote:
>> So basically, the goal of this patch is to ensure that a BEFORE
>> DELETE trigger doesn't silently fail to delete a row because that
>> row was updated during the BEFORE DELETE trigger firing (in our
>> case by secon
I know I'm not the only one to hack up pgbench to create unlogged
tables, so I thought maybe it would be useful to have an option to do
that.
I wasn't excited about picking a single letter option name, so I
modified pgbench to use getopt_long. Patch attached.
--
Robert Haas
EnterpriseDB: http:/
Excerpts from Robert Haas's message of vie jul 22 12:14:30 -0400 2011:
> On Thu, Jul 21, 2011 at 7:51 PM, Alvaro Herrera
> wrote:
> >> I think that there probably ought to be a way to display the NOT NULL
> >> constraint names (perhaps through \d+). For example, if you're
> >> planning to support
On ons, 2011-07-13 at 11:26 -0400, Tom Lane wrote:
> Dean Rasheed writes:
> >>> On 7/12/11 9:46 AM, Andres Freund wrote:
> I guess $subject wasn't implemented because plain unique indexes aren't
> represented in pg_constraint and thus do not have a place to store
> information about
On 07/22/2011 02:09 PM, Joshua D. Drake wrote:
Remember this library follows the RFC for URIs which is why I even
brought it up. If it was just some random parser, I wouldn't even have
bothered. Do we care about the RFC for URIs?
The main components of the RFC involve:
-Decoding escaped chara
On ons, 2011-07-20 at 13:53 -0400, Alvaro Herrera wrote:
> I checked the check_constraints definition in the standard and it's
> not clear to me that NOT NULL constraints are supposed to be there at
> all. Are NOT NULL constraints considered to be CHECK constraints too?
Yes, NOT NULL is considere
On Fri, Jul 22, 2011 at 3:28 PM, Noah Misch wrote:
> On Thu, Jul 21, 2011 at 11:37:27PM -0400, Robert Haas wrote:
>> I think I have a simpler idea, though:
>> before acquiring any locks, just have SIGetDataEntries() do this:
>>
>> + if (stateP->nextMsgNum == segP->maxMsgNum && !stateP->reset
On Thu, Jul 21, 2011 at 11:37:27PM -0400, Robert Haas wrote:
> I think I have a simpler idea, though:
> before acquiring any locks, just have SIGetDataEntries() do this:
>
> + if (stateP->nextMsgNum == segP->maxMsgNum && !stateP->resetState)
> + return 0;
>
> Patch (with comme
On fre, 2011-07-22 at 11:09 -0700, Joshua D. Drake wrote:
> Assuming the code actually makes this patch easier, do we:
>
> A. Pull in the code into the main tree
> B. Instead have it as a requirement via configure?
B
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Fri, Jul 22, 2011 at 5:16 PM, Tom Lane wrote:
> Dave Page writes:
>> On Fri, Jul 22, 2011 at 5:01 PM, Peter Geoghegan
>> wrote:
>>> On 22 July 2011 03:24, Tom Lane wrote:
>> I had a bug filed with Apple about that, and today I got some auto-mail
>> indicating they'd fixed that bug as of OS
On Fri, Jul 22, 2011 at 2:22 PM, Kevin Grittner
wrote:
> "Joshua D. Drake" wrote:
>> I personally think you are handwaving if you think we can
>> build out a robust parser in a couple of hours.
>
> I don't think so. If you have a regular expression engine
> available, you should be able to get t
"Joshua D. Drake" wrote:
> I personally think you are handwaving if you think we can
> build out a robust parser in a couple of hours.
I don't think so. If you have a regular expression engine
available, you should be able to get there by picking one of these
and modifying:
http://regexlib.
On Fri, Jul 22, 2011 at 2:09 PM, Joshua D. Drake wrote:
> I am not neccessarily looking to include it in our tarball. What I asked
> was:
>
> Assuming the code actually makes this patch easier, do we:
>
> A. Pull in the code into the main tree
> B. Instead have it as a requirement via configure?
On 07/22/2011 10:57 AM, Robert Haas wrote:
On Fri, Jul 22, 2011 at 1:26 PM, Joshua D. Drake wrote:
IMHO, it seems like it would be simpler to do that by rolling our own
code rather than importing someone else's.
I mean, look, there is precedent for doing this. We sucked in chunks
of snowbal
On Fri, Jul 22, 2011 at 1:26 PM, Joshua D. Drake wrote:
>> IMHO, it seems like it would be simpler to do that by rolling our own
>> code rather than importing someone else's.
>
> I guess it would depend on how full featured we want the code. The library
> provides validation of various things that
On Jul 15, 2011, at 9:41 AM, Tom Lane wrote:
> Well, actually, that code flat out doesn't work, so whether relistemp is
> available in 9.1 is the least of your problems. Consider what would
> happen if two concurrent sessions did this with the same temp table
> name.
Oh. Duh.
> How about doing
On 07/22/2011 09:03 AM, Robert Haas wrote:
On Fri, Jul 22, 2011 at 11:43 AM, Joshua D. Drake
wrote:
OP of this thread:
http://archives.postgresql.org/pgsql-hackers/2011-07/msg01144.php
It is letting pgsql use URI syntax.
Sorry, I missed that the first time.
IMHO, it seems like it would be
On Fri, Jul 22, 2011 at 12:32 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 22, 2011 at 12:13 PM, Tom Lane wrote:
>>> Well, if you read it that way, then CREATE USER MAPPING with an empty
>>> option set is a no-op: the behavior of the FDW would be the same whether
>>> you'd executed i
On Thu, Jul 21, 2011 at 9:17 PM, Josh Kupershmidt wrote:
> Here's a small patch against branch 8.4 to mention support for COMMENT
> ON index_name.column_name.
I am not in favor of this - because we'd also need to mention every
other relkind that can support comments. I think if we want to do
som
Robert Haas writes:
> On Fri, Jul 22, 2011 at 12:13 PM, Tom Lane wrote:
>> Well, if you read it that way, then CREATE USER MAPPING with an empty
>> option set is a no-op: the behavior of the FDW would be the same whether
>> you'd executed it or not. Which doesn't seem to me to satisfy the
>> pri
On Fri, Jul 22, 2011 at 12:13 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 22, 2011 at 12:02 PM, Tom Lane wrote:
>>> In particular I find the following in SQL-MED:2008 4.14.1:
>>>
>>> NOTE 9 - Privileges granted on foreign tables are not privileges to use
>>> the data constituting fo
Dave Page writes:
> On Fri, Jul 22, 2011 at 5:01 PM, Peter Geoghegan
> wrote:
>> On 22 July 2011 03:24, Tom Lane wrote:
> I had a bug filed with Apple about that, and today I got some auto-mail
> indicating they'd fixed that bug as of OS X 10.7 (Lion). I don't have
> Lion installed here, but I
On Thu, Jul 21, 2011 at 7:51 PM, Alvaro Herrera
wrote:
>> I think that there probably ought to be a way to display the NOT NULL
>> constraint names (perhaps through \d+). For example, if you're
>> planning to support NOT VALID on top of this in the future, then there
>> needs to be a way to get th
Robert Haas writes:
> On Fri, Jul 22, 2011 at 12:02 PM, Tom Lane wrote:
>> In particular I find the following in SQL-MED:2008 4.14.1:
>>
>> NOTE 9 - Privileges granted on foreign tables are not privileges to use
>> the data constituting foreign tables, but privileges to use the
>> definitions of
On Fri, Jul 22, 2011 at 5:01 PM, Peter Geoghegan wrote:
> On 22 July 2011 03:24, Tom Lane wrote:
>> I had a bug filed with Apple about that, and today I got some auto-mail
>> indicating they'd fixed that bug as of OS X 10.7 (Lion). I don't have
>> Lion installed here, but I grabbed the libedit s
On Fri, Jul 22, 2011 at 12:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 22, 2011 at 10:01 AM, Tom Lane wrote:
>>> I am not, however, convinced that that's a legitimate reading of the SQL
>>> spec. Surely user mappings are meant to constrain which users can
>>> connect to a given
On Fri, Jul 22, 2011 at 11:43 AM, Joshua D. Drake
wrote:
> OP of this thread:
>
> http://archives.postgresql.org/pgsql-hackers/2011-07/msg01144.php
>
> It is letting pgsql use URI syntax.
Sorry, I missed that the first time.
IMHO, it seems like it would be simpler to do that by rolling our own
Robert Haas writes:
> On Fri, Jul 22, 2011 at 10:01 AM, Tom Lane wrote:
>> I am not, however, convinced that that's a legitimate reading of the SQL
>> spec. Surely user mappings are meant to constrain which users can
>> connect to a given foreign server.
> Surely that's the job for the table's
On 22 July 2011 03:24, Tom Lane wrote:
> I had a bug filed with Apple about that, and today I got some auto-mail
> indicating they'd fixed that bug as of OS X 10.7 (Lion). I don't have
> Lion installed here, but I grabbed the libedit sources from
> www.opensource.apple.com and indeed it looks fix
Excerpts from Robert Haas's message of vie jul 22 11:33:09 -0400 2011:
> This problem reminds me a great deal of the problems associated with
> managing security labels for SE-Linux. There aren't that many
> distinct values, so ideally it would be nice to store an OID -> string
> mapping somewher
On 07/22/2011 08:36 AM, Robert Haas wrote:
On Fri, Jul 22, 2011 at 10:51 AM, Joshua D. Drake
wrote:
On 07/21/2011 11:13 AM, Tom Lane wrote:
"Joshua D. Drake"writes:
So I am looking intently on what it is going to take to get the URI
patch done for psql [1] and was digging around the we
On 07/21/2011 05:35 AM, Robert Haas wrote:
> On Thu, Jul 21, 2011 at 6:16 AM, Kohei Kaigai
> wrote:
>> How about an idea that allows to launch environment checker (typically shell
>> scripts) prior
>> to regression tests?
>>
>> The following stuffs should be preconfigured to run sepgsql's regres
On Fri, Jul 22, 2011 at 5:00 AM, Harshitha S wrote:
> I am trying to integrate a tracing framework in the Postgres code.
> I need to know if elog.c under backend/utils/error is the place where the
> changes can be made.
Depends on what your tracing framework is trying to do.
> The tracing framew
On Fri, Jul 22, 2011 at 10:51 AM, Joshua D. Drake
wrote:
> On 07/21/2011 11:13 AM, Tom Lane wrote:
>>
>> "Joshua D. Drake" writes:
>>>
>>> So I am looking intently on what it is going to take to get the URI
>>> patch done for psql [1] and was digging around the web and have a URI
>>> parser libr
2011/7/23 Yeb Havinga :
> On 2011-07-22 16:17, Hitoshi Harada wrote:
>>
>> :(
>> I updated the patch. Could you try attached once more? The "issafe"
>> switch seems wrong.
>
> Works like a charm :-). However, now there is always a copyObject of a
> subquery even when the subquery is not safe for qu
On Fri, Jul 22, 2011 at 10:01 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 22.07.2011 11:08, Albe Laurenz wrote:
>>> Or is a user mapping intended to be the only source of
>>> connection information?
>
>> No, you can specify connection details at per-server and
>> per-foreign-table leve
On Thu, Jul 21, 2011 at 7:05 PM, Jim Nasby wrote:
> On Jul 21, 2011, at 5:30 PM, Christopher Browne wrote:
>> - I'd commend capturing NOW() in a timestamptz field. That gives you:
>> 1. What time the DB server thought it was, in terms of UT1
>> 2. What timezone it thought was tied to that conne
Alvaro Herrera writes:
> Does anyone know how do git notes propagate from one repo to another?
> I'm not sure that they are copied on "git push".
> If they don't, they would be pretty useless, so I assume there must be a
> way.
[ googles... ] According to
http://progit.org/2010/08/25/notes.html
Excerpts from Andres Freund's message of sáb jul 02 10:19:07 -0400 2011:
> On Saturday, July 02, 2011 06:10:43 AM Tom Lane wrote:
> > I wouldn't have a problem with establishing a convention that we
> > write credits in commit messages in a more standardized way, ie put
> > something like "Author:
On 2011-07-22 16:17, Hitoshi Harada wrote:
:(
I updated the patch. Could you try attached once more? The "issafe"
switch seems wrong.
Works like a charm :-). However, now there is always a copyObject of a
subquery even when the subquery is not safe for qual pushdown. The
problem with the previ
On 07/21/2011 11:13 AM, Tom Lane wrote:
"Joshua D. Drake" writes:
So I am looking intently on what it is going to take to get the URI
patch done for psql [1] and was digging around the web and have a URI
parser library. It is under the New BSD license and is strictly RFC RFC
3986 [2] compliant
Could you try attached once more? The "issafe"
switch seems wrong.
Thanks,
--
Hitoshi Harada
aggjoin-20110722.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Heikki Linnakangas writes:
> On 22.07.2011 11:08, Albe Laurenz wrote:
>> Or is a user mapping intended to be the only source of
>> connection information?
> No, you can specify connection details at per-server and
> per-foreign-table level too. The FDW implementation is free to accept or
> reje
On 2011-07-02 10:02, Hitoshi Harada wrote:
Although I still need to think about suitable regression test case,
the patch itself can be reviewed again. You may want to try some
additional tests as you imagine after finding my test case gets
quicker.
Hello Hitoshi-san,
I took a look at your la
On 2011-07-21 11:29, Kohei Kaigai wrote:
The attached patch is revised userspace-avc patch.
List of updates:
- The GUC of sepgsql.avc_threshold was removed.
- "char *ucontext" of avc_cache was replaced by "bool tcontext_is_valid".
- Comments added onto static variables
- Comments of sepgsql_avc_
2011/7/22 Yeb Havinga :
> On 2011-07-22 11:55, Kohei Kaigai wrote:
>>
>>> 2) Also I thought if it could work to not remember tcontext is valid, but
>>> instead remember the consequence,
>>> which is that it is replaced by "unlabeled". It makes the avc_cache
>>> struct shorter and the code somewhat
Heikki Linnakangas wrote:
>> I guess I misunderstood the concept of user mapping.
>> I guess it is time to read my SQL Standard, but some clarification
>> in the documentation sure wouldn't hurt.
>
> Agreed, there doesn't seem to be any documentation on user mappings,
> aside from the reference pa
On 2011-07-22 11:55, Kohei Kaigai wrote:
2) Also I thought if it could work to not remember tcontext is valid, but
instead remember the consequence,
which is that it is replaced by "unlabeled". It makes the avc_cache struct
shorter and the code somewhat
simpler.
Here is a reason why we hold
> -Original Message-
> From: Yeb Havinga [mailto:yebhavi...@gmail.com]
> Sent: 22. Juli 2011 10:23
> To: Kohei Kaigai
> Cc: Robert Haas; PgHacker; Kohei KaiGai
> Subject: Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache
>
> On 2011-07-21 11:29, Kohei Kaigai wrote:
> > The attac
Hi!
Patch with my try to detect ordered datasets is attached. The implemented
idea is desribed below.
Index tuples are divided by chunks of 128. On each chunk we measure how much
leaf pages where index tuples was inserted don't match those of previous
chunk. Based on statistics of several chunks w
On 22.07.2011 11:08, Albe Laurenz wrote:
Tom Lane wrote:
1) GetUserMapping throws an error if there is no
user mapping for the user (or PUBLIC).
I think that it would be much more useful if
it would return NULL or something similar instead.
We could make it do that, but under what
Hi,
I am trying to integrate a tracing framework in the Postgres code.
I need to know if elog.c under backend/utils/error is the place where the
changes can be made.
The tracing framework that I want to integrate has some additional
capability. I want to replace the tracing and logging functiona
Tom Lane wrote:
>> 1) GetUserMapping throws an error if there is no
>>user mapping for the user (or PUBLIC).
>>I think that it would be much more useful if
>>it would return NULL or something similar instead.
> We could make it do that, but under what circumstances would it be
> useful
On 21.07.2011 21:05, Alvaro Herrera wrote:
Excerpts from Simon Riggs's message of jue jul 21 13:30:25 -0400 2011:
I think I'll just revert it though. Subtransactions need a lot of
tuning but this isn't high enough up my list to be worth the work.
If it works and is sane, why would you revert
71 matches
Mail list logo
