Re: [HACKERS] the big picture for index-only scans

On Wed, May 11, 2011 at 12:54 AM, Greg Stark wrote: > On a separate note though, Simon, I don't know what you mean by "we > normally start with a problem". It's an free software project and > people are free to work on whatever interests them whether that's > because it solves a problem they have

Re: [HACKERS] Feature proposal: distinguish each PostgreSQL instance in the event log

On Tue, May 10, 2011 at 11:55 PM, Tom Lane wrote: > "MauMau" writes: >>> "MauMau" writes: I've encountered one problem on Windows. I need to support running all of my products on one host simultaneously. Plus, I need to log messages in syslog/event log. On Linux, I can distin

Re: [HACKERS] Foreign table permissions and cloning

(2011/04/26 5:42), Robert Haas wrote: > OK. Turned out a little more cleanup was needed to make this all the > way consistent with how we handle views; I have now done that. I noticed that some fixes would be needed for consistency about foreign table privileges. Attached patch includes fixes bel

Re: [HACKERS] the big picture for index-only scans

On Wed, May 11, 2011 at 1:47 AM, Bruce Momjian wrote: > Greg Stark wrote: >> On a separate note though, Simon, I don't know what you mean by "we >> normally start with a problem". It's an free software project and >> people are free to work on whatever interests them whether that's >> because it s

Re: [HACKERS] the big picture for index-only scans

On Wed, May 11, 2011 at 2:34 AM, Bruce Momjian wrote: > Robert Haas wrote: >> So, what do we need in order to find our way to index-only scans? >> >> 1. The visibility map needs to be crash-safe.  The basic idea of >> index-only scans is that, instead of checking the heap to find out >> whether ea

[HACKERS] potential bug in trigger with boolean params

Hi, I was trying to create a trigger with parameters. I've found a potential bug when the param is boolean. Here is code replicating the bug: CREATE TABLE x(x TEXT); CREATE OR REPLACE FUNCTION trigger_x() RETURNS TRIGGER AS $$ BEGIN RETURN NEW; END; $$ LANGUAGE PLPGSQL; CREATE TRIGGER t

Re: [HACKERS] Process wakeups when idle and power consumption

On 9 May 2011 11:19, Heikki Linnakangas wrote: > In the child, spawn a thread How exactly should I go about this? The one place in the code that I knew to use multiple threads, pgbench, falls back on "emulation with fork()" on some platforms. -- Peter Geoghegan       http://www.2ndQuadrant.com

Re: [HACKERS] the big picture for index-only scans

On 10.05.2011 20:15, Simon Riggs wrote: On Tue, May 10, 2011 at 5:17 PM, Kevin Grittner wrote: Simon Riggs wrote: This topic has been discussed many times, yet I have never seen an assessment that explains WHY we would want to do index-only scans. In databases with this feature, it's not

Re: [HACKERS] Process wakeups when idle and power consumption

On Wed, May 11, 2011 at 10:52, Peter Geoghegan wrote: > On 9 May 2011 11:19, Heikki Linnakangas > wrote: > >> In the child, spawn a thread > > How exactly should I go about this? The one place in the code that I > knew to use multiple threads, pgbench, falls back on "emulation with > fork()" on s

Re: [HACKERS] potential bug in trigger with boolean params

> Hi, > I was trying to create a trigger with parameters. I've found a potential > bug > when the param is boolean. > > Here is code replicating the bug: > > CREATE TABLE x(x TEXT); > > CREATE OR REPLACE FUNCTION trigger_x() RETURNS TRIGGER AS $$ > BEGIN > RETURN NEW; > END; $$ LANGUAGE PLP

Re: [HACKERS] potential bug in trigger with boolean params

On 11 May 2011 10:56, wrote: > > Hi, > > I was trying to create a trigger with parameters. I've found a potential > > bug > > when the param is boolean. > > > > Here is code replicating the bug: > > > > CREATE TABLE x(x TEXT); > > > > CREATE OR REPLACE FUNCTION trigger_x() RETURNS TRIGGER AS $$ >

Re: [HACKERS] potential bug in trigger with boolean params

På onsdag 11. mai 2011 kl 10:56:19 skrev : > > Hi, > > I was trying to create a trigger with parameters. I've found a potential > > bug > > when the param is boolean. > > > > Here is code replicating the bug: > > > > CREATE TABLE x(x TEXT); > > > > CREATE OR REPLACE FUNCTION trigger_x() RETURNS TRI

Re: [HACKERS] potential bug in trigger with boolean params

On Wednesday, May 11, 2011 11:01:56 AM Andreas Joseph Krogh wrote: > På onsdag 11. mai 2011 kl 10:56:19 skrev : > > > CREATE TRIGGER trig_x_bool BEFORE INSERT ON x FOR EACH ROW EXECUTE > > > PROCEDURE > > > trigger_x(true); > > The docs clearly state what the valid values are and the literal 'true'

Re: [HACKERS] time-delayed standbys

On 07.05.2011 16:48, Robert Haas wrote: I was able to reproduce something very like this in unpatched master, just by letting recovery pause at a named restore point, and then resuming it. LOG: recovery stopping at restore point "stop", time 2011-05-07 09:28:01.652958-04 LOG: recovery has paus

Re: [HACKERS] potential bug in trigger with boolean params

On Wednesday, May 11, 2011 11:21:34 AM Andres Freund wrote: > On Wednesday, May 11, 2011 11:01:56 AM Andreas Joseph Krogh wrote: > > På onsdag 11. mai 2011 kl 10:56:19 skrev : > > > > CREATE TRIGGER trig_x_bool BEFORE INSERT ON x FOR EACH ROW EXECUTE > > > > PROCEDURE > > > > trigger_x(true); > > >

Re: [HACKERS] potential bug in trigger with boolean params

On 11 May 2011 11:01, Andreas Joseph Krogh wrote: > På onsdag 11. mai 2011 kl 10:56:19 skrev : > > > Hi, > > > I was trying to create a trigger with parameters. I've found a > potential > > > bug > > > when the param is boolean. > > > > > > Here is code replicating the bug: > > > > > > CREATE TAB

[HACKERS] Re: 4.1beta1: ANYARRAY disallowed for DOMAIN types which happen to be arrays

On Mon, May 09, 2011 at 11:32:28PM -0400, Tom Lane wrote: > To be concrete, consider the function array_append(anyarray, anyelement) > yielding anyarray. Suppose we have a domain D over int[] and the call > array_append(var_of_type_D, 42). If we automatically downcast the > variable to int[], sho

Re: [HACKERS] the big picture for index-only scans

2011/5/11, Bruce Momjian : > FYI, because the visibility map is only one _bit_ per page, it is 8000 * > 8 or 64k times smaller than the heap, e.g. one 8k page covers 64MB of > heap pages. Actually, that would be "one 8kB block covers 512MB of heap": 1 block of visibility map (8kB) = 64k visibilit

Re: [HACKERS] potential bug in trigger with boolean params

På onsdag 11. mai 2011 kl 11:30:51 skrev Szymon Guz : On 11 May 2011 11:01, Andreas Joseph Krogh wrote: På onsdag 11. mai 2011 kl 10:56:19 skrev :   > > Hi, > > I was trying to create a trigger with parameters. I've found a potential >

Re: [HACKERS] time-delayed standbys

On 11.05.2011 08:29, Fujii Masao wrote: On Sat, May 7, 2011 at 10:48 PM, Robert Haas wrote: I was able to reproduce something very like this in unpatched master, just by letting recovery pause at a named restore point, and then resuming it. I was able to reproduce the same problem even in 9.0

Re: [HACKERS] the big picture for index-only scans

2011/5/11 Heikki Linnakangas : > On 10.05.2011 20:15, Simon Riggs wrote: >> >> On Tue, May 10, 2011 at 5:17 PM, Kevin Grittner >>  wrote: >>> >>> Simon Riggs  wrote: >>> This topic has been discussed many times, yet I have never seen an assessment that explains WHY we would want to do in

Re: [HACKERS] potential bug in trigger with boolean params

On Wednesday, May 11, 2011 11:50:35 AM Szymon Guz wrote: > On 11 May 2011 11:29, Andres Freund wrote: > > On Wednesday, May 11, 2011 11:21:34 AM Andres Freund wrote: > > > On Wednesday, May 11, 2011 11:01:56 AM Andreas Joseph Krogh wrote: > > > > På onsdag 11. mai 2011 kl 10:56:19 skrev : > > > >

Re: [HACKERS] the big picture for index-only scans

2011/5/10 Kevin Grittner : > Simon Riggs wrote: >> The typical speed up for non-covered indexes will come when we >> access a very large table (not in cache) via an index scan that is >> smaller than a bitmapindex scan. Will we be able to gauge >> selectivities sufficiently accurately to be able t

Re: [HACKERS] potential bug in trigger with boolean params

On 11 May 2011 12:06, Andres Freund wrote: > > Why do you wan't to use a boolean directly if you can't use it as the type > itself anyway? > > Yep, and this is a really good point :) I wanted to have consistent api, so use true when I have a boolean value. I will use 'true' and add some info on t

Re: [HACKERS] Process wakeups when idle and power consumption

On 11 May 2011 09:54, Magnus Hagander wrote: > If you're doing this Win32 specific, take a look at > src/backend/port/win32/signal.c for an example. > > If you're not doing this win32-specific, I doubt we really want > threads to be involved... Well, that seems to be the traditional wisdom. It s

Re: [HACKERS] Process wakeups when idle and power consumption

On 11.05.2011 13:34, Peter Geoghegan wrote: On 11 May 2011 09:54, Magnus Hagander wrote: If you're doing this Win32 specific, take a look at src/backend/port/win32/signal.c for an example. If you're not doing this win32-specific, I doubt we really want threads to be involved... Well, that s

Re: [HACKERS] the big picture for index-only scans

On Tue, May 10, 2011 at 9:34 PM, Bruce Momjian wrote: > Robert Haas wrote: >> So, what do we need in order to find our way to index-only scans? >> >> 1. The visibility map needs to be crash-safe.  The basic idea of >> index-only scans is that, instead of checking the heap to find out >> whether ea

Re: [HACKERS] the big picture for index-only scans

On Tue, May 10, 2011 at 10:29 PM, Tom Lane wrote: > That will be true only if you intentionally ignore the points Greg > raised.  If the table isn't entirely ALL_VISIBLE, then the choice of > index will determine the ordering of the actual table probes that occur. > There could be more or fewer pa

Re: [HACKERS] time-delayed standbys

On Wed, May 11, 2011 at 6:50 PM, Heikki Linnakangas wrote: > I think we can just always call ShutdownWalRcv(). It should be gone if the > server was promoted while streaming, but that's just an implementation > detail of what the promotion code does. There's no hard reason why it > shouldn't be ru

Re: [HACKERS] the big picture for index-only scans

On Wed, May 11, 2011 at 3:17 AM, Simon Riggs wrote: > Completely agree, but why are you saying that to me? > > When Tom asks me why I suggest something, nobody tells him "its a free > software project etc...". > > What is the difference here? We're now 40 emails in this thread, and there seems to

Re: [HACKERS] Feature proposal: distinguish each PostgreSQL instance in the event log

From: "Dave Page" On Tue, May 10, 2011 at 11:55 PM, Tom Lane wrote: BTW, what will this accomplish exactly that couldn't be accomplished by setting log_line_prefix to include the desired identifier? Windows uses the event source field to show where events in the logs have come from. The Even

Re: [HACKERS] time-delayed standbys

On 11.05.2011 14:16, Fujii Masao wrote: On Wed, May 11, 2011 at 6:50 PM, Heikki Linnakangas wrote: I think we can just always call ShutdownWalRcv(). It should be gone if the server was promoted while streaming, but that's just an implementation detail of what the promotion code does. There's n

Re: [HACKERS] VARIANT / ANYTYPE datatype

On Tue, May 10, 2011 at 10:29 PM, Joseph Adams wrote: > It seems to me a reasonable way to implement VARIANT would be to have > a data type called VARIANT that stores an OID of the inner type at the > beginning, followed by the binary data. That's likely to be how it gets implemented, but you see

[HACKERS] Patch to allow domains over composite types

typecmds.c says: "Domains over composite types might be made to work in the future, but not today." Attached is a patch that allows domains over composite types, together with test cases in domaincomp.sql. A domain over a composite type has typtype TYPTYPE_DOMAIN, but typrelid and typrelkind

Re: [HACKERS] crash-safe visibility map, take five

On Tue, May 10, 2011 at 7:38 PM, Robert Haas wrote: > On Tue, May 10, 2011 at 9:45 AM, Merlin Moncure > wrote: > > I see: here's a comment that was throwing me off: > > + /* > > +* If we didn't get the lock and it turns out we need it, we'll > have to > > +* unlock and re-l

Re: [HACKERS] VARIANT / ANYTYPE datatype

On 05/11/2011 07:53 AM, Robert Haas wrote: On Tue, May 10, 2011 at 10:29 PM, Joseph Adams wrote: It seems to me a reasonable way to implement VARIANT would be to have a data type called VARIANT that stores an OID of the inner type at the beginning, followed by the binary data. That's likely

Re: [HACKERS] the big picture for index-only scans

Nicolas Barbier wrote: > 2011/5/11, Bruce Momjian : > > > FYI, because the visibility map is only one _bit_ per page, it is 8000 * > > 8 or 64k times smaller than the heap, e.g. one 8k page covers 64MB of > > heap pages. > > Actually, that would be "one 8kB block covers 512MB of heap": 1 block >

Re: [HACKERS] the big picture for index-only scans

Simon Riggs wrote: > On Wed, May 11, 2011 at 1:47 AM, Bruce Momjian wrote: > > Greg Stark wrote: > >> On a separate note though, Simon, I don't know what you mean by "we > >> normally start with a problem". It's an free software project and > >> people are free to work on whatever interests them w

Re: [HACKERS] Re: 4.1beta1: ANYARRAY disallowed for DOMAIN types which happen to be arrays

Noah Misch writes: > On Mon, May 09, 2011 at 11:32:28PM -0400, Tom Lane wrote: >> So we basically had three alternatives to make it better: >> * downcast to the array type, which would possibly silently >>break applications that were relying on the function result >>being cons

Re: [HACKERS] the big picture for index-only scans

C?dric Villemain wrote: > 2011/5/10 Kevin Grittner : > > Simon Riggs wrote: > >> The typical speed up for non-covered indexes will come when we > >> access a very large table (not in cache) via an index scan that is > >> smaller than a bitmapindex scan. Will we be able to gauge > >> selectivities

Re: [HACKERS] PGC_S_DEFAULT is inadequate

On Wed, May 11, 2011 at 3:20 AM, Tom Lane wrote: > So this is fine if the > current value was from the file or was the boot_val, but if we'd > overridden the boot value with a "replacement" default value using > PGC_S_DEFAULT, that code would cause the value to revert to the boot_val > not the rep

Re: [HACKERS] the big picture for index-only scans

Bruce Momjian wrote: >> The very fact that Kevin and yourself bring up different reasons >> for why we need this feature makes me nervous. > > Yes, no question. For count(*), you don't care about the indexed > values, only the count, while for Kevin's case you are reading > values from the ind

Re: [HACKERS] the big picture for index-only scans

Heikki Linnakangas writes: > On 10.05.2011 20:15, Simon Riggs wrote: >> I can picture that. Regrettably, I can also picture the accesses to >> the visibility map, the maintenance operations on the VM that are >> needed for this and the contention that both of those will cause. > I agree that we n

[HACKERS] Fix for bug in ldapServiceLookup in libpq

I have found a small but annoying bug in libpq where connection parameters are resolved via LDAP. There is a write past the end of a malloc'ed string which causes memory corruption. The code and the bug are originally by me :^( The attached patch fixes the problem in HEAD. This should be backpatc

Re: [HACKERS] the big picture for index-only scans

Tom Lane wrote: > Heikki Linnakangas writes: > > On 10.05.2011 20:15, Simon Riggs wrote: > >> I can picture that. Regrettably, I can also picture the accesses to > >> the visibility map, the maintenance operations on the VM that are > >> needed for this and the contention that both of those will c

Re: [HACKERS] PGC_S_DEFAULT is inadequate

Greg Stark writes: > On Wed, May 11, 2011 at 3:20 AM, Tom Lane wrote: >> So this is fine if the >> current value was from the file or was the boot_val, but if we'd >> overridden the boot value with a "replacement" default value using >> PGC_S_DEFAULT, that code would cause the value to revert to

Re: [HACKERS] hint bit cache v5

On Tue, May 10, 2011 at 11:59 AM, Simon Riggs wrote: > On Mon, May 9, 2011 at 5:12 PM, Merlin Moncure wrote: > >> I'd like to know if this is a strategy that merits further work...If >> anybody has time/interest that is.  It's getting close to the point >> where I can just post it to the commit f

Re: [HACKERS] VARIANT / ANYTYPE datatype

On Wed, May 11, 2011 at 7:53 AM, Robert Haas wrote: > That's likely to be how it gets implemented, but you seem to have > missed the point of some of the discussion upthread: the big problem > with that is that someone might type "DROP TYPE foo", and when they > do, you need an efficient way to fi

Re: [HACKERS] Fix for bug in ldapServiceLookup in libpq

"Albe Laurenz" writes: > I have found a small but annoying bug in libpq where > connection parameters are resolved via LDAP. > There is a write past the end of a malloc'ed string which causes > memory corruption. The code and the bug are originally by me :^( Hmm ... that's a bug all right, but w

Re: [HACKERS] the big picture for index-only scans

Tom Lane wrote: > I think Simon's point is that showing a gain on specific test > cases isn't a sufficient argument. Ah, if that's what he's been trying to get at, I'm curious who disagrees with that. I wouldn't have thought anyone on this list would. > What we need to know about this sort

Re: [HACKERS] VARIANT / ANYTYPE datatype

Excerpts from Simon Riggs's message of mar may 10 17:57:20 -0400 2011: > On Wed, May 4, 2011 at 5:58 PM, Alvaro Herrera > wrote: > > both Oracle and MS-SQL have it > > Do they? What types are they called? ANYTYPE -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Rep

Re: [HACKERS] VARIANT / ANYTYPE datatype

On Wed, May 11, 2011 at 11:43 AM, Joseph Adams wrote: > On Tue, May 10, 2011 at 5:19 PM, Darren Duncan > wrote: >> Examples of open union types could be number, which all the numeric types >> compose, and so you can know say that you can use the generic numeric >> operators on values you have si

Re: [HACKERS] Fix for bug in ldapServiceLookup in libpq

... btw, shouldn't this function free the "result" string when it's done with it? AFAICS that string is not returned to the caller, it's just being leaked. (I'll refrain from asking why it's creating the string in the first place rather than parsing ldap_get_values_len's output as-is ...)

Re: [HACKERS] hint bit cache v5

On Wed, May 11, 2011 at 10:38 AM, Merlin Moncure wrote: > One thing I need to test is how much benefit you'll see with wider records. The results are a bit better, around 25% using a similar methodology on ~ 1k wide records. > I think I'm gonna revert the change to cache invalid bits. I just > d

[HACKERS] Standbys which don't synch to disk?

Fujii, Simon, For 9.1, both master and replica in a sync replication relationship are required to be fsync'ing to disk. I understand why we had to do that for our first cut at synch rep. Do you think, though, that it might become possible to replicate without synch-to-disk for 9.2? The use case

Re: [HACKERS] Standbys which don't synch to disk?

On Wed, May 11, 2011 at 1:12 PM, Josh Berkus wrote: > For 9.1, both master and replica in a sync replication relationship are > required to be fsync'ing to disk.  I understand why we had to do that > for our first cut at synch rep.  Do you think, though, that it might > become possible to replicat

Re: [HACKERS] potential bug in trigger with boolean params

Andres Freund writes: >> The grammar accepts only a very limited amount of parameters there: > Err > TriggerFuncArg: > Iconst > { > char buf[64]; > snprintf(buf, sizeof(buf), "%d", $1); > $$ = makeString(p

Re: [HACKERS] Standbys which don't synch to disk?

> It's already possible to set fsync=off on the standby if you want. If > there is an OS-level crash you'll need to rebuild the standby, but in > some cases that may be acceptable. Yes, generally if there's an OS-level crash on cloud hosting, you've lost the instance anyway. > And Simon has alr

[HACKERS] pg_upgrade and PGPORT

pg_upgrade is a bit schizophrenic concerning the PGPORT environment variable. On the one hand, there is this code in option.c that wants to make use of it: old_cluster.port = getenv("PGPORT") ? atoi(getenv("PGPORT")) : DEF_PGPORT; new_cluster.port = getenv("PGPORT") ? atoi(getenv("PGPORT"

Re: [HACKERS] hint bit cache v5

On Wed, May 11, 2011 at 4:38 PM, Merlin Moncure wrote: > Following are results that are fairly typical of the benefits you > might see when the optimization kicks in.  The attached benchmark just > [hbcache] > real    3m35.549s > [HEAD] > real    4m24.216s These numbers look very good. Thanks

Re: [HACKERS] pg_upgrade and PGPORT

Peter Eisentraut wrote: > pg_upgrade is a bit schizophrenic concerning the PGPORT environment > variable. On the one hand, there is this code in option.c that wants to > make use of it: > > old_cluster.port = getenv("PGPORT") ? atoi(getenv("PGPORT")) : DEF_PGPORT; > new_cluster.port = get

Re: [HACKERS] potential bug in trigger with boolean params

On Wednesday, May 11, 2011 07:25:58 PM Tom Lane wrote: > Andres Freund writes: > >> The grammar accepts only a very limited amount of parameters there: > > Err > > > > TriggerFuncArg: > > Iconst > > > > { > > > > ch

Re: [HACKERS] Standbys which don't synch to disk?

Josh Berkus writes: >> It's already possible to set fsync=off on the standby if you want. If >> there is an OS-level crash you'll need to rebuild the standby, but in >> some cases that may be acceptable. > ... The one other thing would be the > ability not to fsync the master, which would come

Re: [HACKERS] potential bug in trigger with boolean params

Andres Freund writes: > Is there a special reason for not using the normal function calling > mechanisms? It looks to me as it was just done to have an easy way to store > it > in pg_trigger.tgargs. Well, this is all very historical, dating from Berkeley days AFAIK. If we had it to do over, I

Re: [HACKERS] pg_upgrade and PGPORT

Bruce Momjian writes: > A larger question is whether we should just disable all the checks for > environment variables. The C comment says: > * check_for_libpq_envvars() > * > * tests whether any libpq environment variables are set. > * Since pg_upgrade connects to both the old and the new s

Re: [HACKERS] pg_upgrade and PGPORT

Tom Lane wrote: > Bruce Momjian writes: > > A larger question is whether we should just disable all the checks for > > environment variables. The C comment says: > > > * check_for_libpq_envvars() > > * > > * tests whether any libpq environment variables are set. > > * Since pg_upgrade connec

Re: [HACKERS] hint bit cache v5

On Wed, May 11, 2011 at 12:40 PM, Simon Riggs wrote: > On Wed, May 11, 2011 at 4:38 PM, Merlin Moncure wrote: > >> Following are results that are fairly typical of the benefits you >> might see when the optimization kicks in.  The attached benchmark just > >> [hbcache] >> real    3m35.549s > >> [

[HACKERS] Tables cannot have INSTEAD OF triggers

Why not? Is there a fundamental problem, or just that no one wanted to make it work? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_upgrade and PGPORT

On Wed, May 11, 2011 at 2:18 PM, Tom Lane wrote: > Or you could just "unsetenv" instead of complaining. +1 for that. > I would like to think that eventually pg_upgrade won't start a > postmaster at all, but connect using something more like a standalone > backend.  So someday the issue might go

Re: [HACKERS] Standbys which don't synch to disk?

Robert, > > That WAL has effectively disappeared from the > > master, but is still present on the slave. Now the master comes up > > and starts processing read-write transactions again, and generates a > > new and different 1kB of WAL. Hilarity ensues, because the two > > machines are now out of

Re: [HACKERS] Unfriendly handling of pg_hba SSL options with SSL off

On Tue, May 10, 2011 at 05:39, Tom Lane wrote: > Bruce Momjian writes: >> Late reply, but we are basically ignoring 'local' lines if the build >> doesn't support unix domain sockets (windows), but throwing an error for >> hostssl usage if ssl is not compiled in.  Is the only logic here that >> 'l

Re: [HACKERS] Tables cannot have INSTEAD OF triggers

Peter Eisentraut writes: > Why not? Is there a fundamental problem, or just that no one wanted to > make it work? I'm fairly sure there was a substantive issue, but memory fails as to what it was. You could try removing the error check and see what breaks ... regards, t

Re: [HACKERS] VARIANT / ANYTYPE datatype

Robert Haas wrote: On Wed, May 11, 2011 at 11:43 AM, Joseph Adams wrote: On Tue, May 10, 2011 at 5:19 PM, Darren Duncan wrote: Examples of open union types could be number, which all the numeric types compose, and so you can know say that you can use the generic numeric operators on values yo

Re: [HACKERS] Re: 4.1beta1: ANYARRAY disallowed for DOMAIN types which happen to be arrays

On Wed, May 11, 2011 at 10:22:01AM -0400, Tom Lane wrote: > Noah Misch writes: > > On Mon, May 09, 2011 at 11:32:28PM -0400, Tom Lane wrote: > >> So we basically had three alternatives to make it better: > >>* downcast to the array type, which would possibly silently > >> break applicatio

Re: [HACKERS] VARIANT / ANYTYPE datatype

To follow-up my earlier comments ... I suspect for practical purposes we may want to limit the scope of some type features. For example, the greatest benefits for "open union" / "mixin" types is with routines/operators, not so much with tables. So, Pg could choose to support open unions but

Re: [HACKERS] Patch to allow domains over composite types

On Wed, May 11, 2011 at 8:07 AM, Yeb Havinga wrote: > typecmds.c says: > "Domains over composite types might be made to work in the future, but not > today." > > Attached is a patch that allows domains over composite types, together with > test cases in domaincomp.sql. A domain over a composite ty

Re: [HACKERS] Collation mega-cleanups

On mån, 2011-05-09 at 14:58 -0400, Bruce Momjian wrote: > Tom this collation stuff has seen more post-feature-commit cleanups > than I think any patch I remember. Is there anything we can learn > from this? Don't do big patches? Seriously, it looks pretty bad, but this is one of the biggest feat

Re: [HACKERS] Backpatching of "Teach the regular expression functions to do case-insensitive matching"

On tis, 2011-05-10 at 18:05 -0400, Tom Lane wrote: > The lack of initdb support for getting more-or-less-standard collation > entries into pg_collation on Windows seems to be the major missing > piece from here (dunno if Peter is aware of others). If we don't fix > that before release, we're going

Re: [HACKERS] Collation mega-cleanups

Peter Eisentraut wrote: > from that? The bigger your patch, the lonelier you are. I can attest to that. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers

Re: [HACKERS] Collation mega-cleanups

Peter Eisentraut writes: > Seriously, it looks pretty bad, but this is one of the biggest feature > patches in the last 5 years, it touches many places all over the system, > and there is a reason why this topic has been on the TODO list for 10 > years: it's overwhelming. Yeah. I did not want to

Re: [HACKERS] Backpatching of "Teach the regular expression functions to do case-insensitive matching"

Peter Eisentraut writes: > On tis, 2011-05-10 at 18:05 -0400, Tom Lane wrote: >> The lack of initdb support for getting more-or-less-standard collation >> entries into pg_collation on Windows seems to be the major missing >> piece from here (dunno if Peter is aware of others). If we don't fix >>

Re: [HACKERS] VARIANT / ANYTYPE datatype

Darren Duncan writes: > But I'm just citing numeric as an example; there would be a lot more > in practice, potentially one for every individual type, so for example > if operators were defined for the open union rather than for the base > type, then users/extensions could define their own types a

Re: [HACKERS] Extension Packaging

On Apr 28, 2011, at 2:16 PM, David E. Wheeler wrote: > So maybe it's half-assed. Maybe the version can be anything but the revision > must be an integer. Maybe there's a `pg_extension_version($extension_name)` > function that returns ARRAY[$version, $revision], and the revision is set in > the

Re: [HACKERS] Backpatching of "Teach the regular expression functions to do case-insensitive matching"

On ons, 2011-05-11 at 16:47 -0400, Tom Lane wrote: > Hm, do you know how to enumerate the available locales on Windows? EnumSystemLocalesEx() Reference: http://msdn.microsoft.com/en-us/library/dd317829(v=vs.85).aspx Example: http://msdn.microsoft.com/en-us/library/dd319091(v=vs.85).aspx As you

Re: [HACKERS] Backpatching of "Teach the regular expression functions to do case-insensitive matching"

Peter Eisentraut writes: > On ons, 2011-05-11 at 16:47 -0400, Tom Lane wrote: >> Hm, do you know how to enumerate the available locales on Windows? > EnumSystemLocalesEx() > Reference: > http://msdn.microsoft.com/en-us/library/dd317829(v=vs.85).aspx > Example: http://msdn.microsoft.com/en-us/li

[HACKERS] performance-test farm

Hi everyone, several members of this mailing list mentioned recently it'd be really useful to have a performance-test farm, that it might improve the development process and make some changes easier. I've briefly discussed this with another CSPUG member, who represents a local company using Postg

Re: [HACKERS] performance-test farm

Tomas Vondra wrote: > 1) Is there something that might serve as a model? I've been assuming that we would use the PostgreSQL Buildfarm as a model. http://buildfarm.postgresql.org/ > 2) How would you use it? What procedure would you expect? People who had suitable test environments could

Re: [HACKERS] Extension Packaging

On Wed, May 11, 2011 at 5:06 PM, David E. Wheeler wrote: > On Apr 28, 2011, at 2:16 PM, David E. Wheeler wrote: > >> So maybe it's half-assed. Maybe the version can be anything but the revision >> must be an integer. Maybe there's a `pg_extension_version($extension_name)` >> function that return

Re: [HACKERS] performance-test farm

Dne 11.5.2011 23:41, Kevin Grittner napsal(a): > Tomas Vondra wrote: > >> 1) Is there something that might serve as a model? > > I've been assuming that we would use the PostgreSQL Buildfarm as a > model. > > http://buildfarm.postgresql.org/ Yes, I was thinking about that too, but 1) A bui

Re: [HACKERS] Prefered Types

Excerpts from Tom Lane's message of dom may 08 23:00:27 -0400 2011: > For > example, if you start noticing an occasional integer overflow that > didn't happen before, it might be pretty darn difficult to figure out > that the problem is that an operation that was formerly resolved as int4 > + int4

Re: [HACKERS] XML with invalid chars

On 05/09/2011 11:25 PM, Noah Misch wrote: I see you've gone with doing it unconditionally. I'd lean toward testing the library in pg_xml_init and setting a flag indicating whether we need the extra pass. However, a later patch can always optimize that. I wasn't terribly keen on the idea,

Re: [HACKERS] performance-test farm

Tomas Vondra wrote: > Dne 11.5.2011 23:41, Kevin Grittner napsal(a): >> Tomas Vondra wrote: >> >>> 1) Is there something that might serve as a model? >> >> I've been assuming that we would use the PostgreSQL Buildfarm as >> a model. >> >> http://buildfarm.postgresql.org/ > > Yes, I was thi

Re: [HACKERS] pg_upgrade and PGPORT

Robert Haas wrote: > On Wed, May 11, 2011 at 2:18 PM, Tom Lane wrote: > > Or you could just "unsetenv" instead of complaining. > > +1 for that. OK, the attached patch does this, but allows PGCLIENTENCODING to be passed in. The new output looks like: Performing Consistency Checks

Re: [HACKERS] performance-test farm

Dne 12.5.2011 00:21, Kevin Grittner napsal(a): > Tomas Vondra wrote: >> Dne 11.5.2011 23:41, Kevin Grittner napsal(a): >>> Tomas Vondra wrote: >>> 1) Is there something that might serve as a model? >>> >>> I've been assuming that we would use the PostgreSQL Buildfarm as >>> a model. >>>

Re: [HACKERS] performance-test farm

On 05/11/2011 06:21 PM, Kevin Grittner wrote: Tomas Vondra wrote: Dne 11.5.2011 23:41, Kevin Grittner napsal(a): Tomas Vondra wrote: First up, you guys should be aware that Greg Smith at least is working on this. Let's not duplicate effort. 1) Is there something that might serve a

Re: [HACKERS] XML with invalid chars

On Wed, May 11, 2011 at 06:17:07PM -0400, Andrew Dunstan wrote: > On 05/09/2011 11:25 PM, Noah Misch wrote: >> SELECT xmlcomment(E'\ufffe'); > > That's a bit harder. Do we want to extend these checks to cover > surrogates and end of plane characters, which are the remaining > forbidden chars? I

[HACKERS] Help: regarding patch development

Hello,   Sir, i want to develop a service for postgresql related to querry processing.but i dont know how to develop it. plz guide me so that i can take step. i will be realy thankful to you.   Regards Emman

Re: [HACKERS] XML with invalid chars

On 05/11/2011 07:00 PM, Noah Misch wrote: On Wed, May 11, 2011 at 06:17:07PM -0400, Andrew Dunstan wrote: On 05/09/2011 11:25 PM, Noah Misch wrote: SELECT xmlcomment(E'\ufffe'); That's a bit harder. Do we want to extend these checks to cover surrogates and end of plane characters, which are

Re: [HACKERS] performance-test farm

* Andrew Dunstan (and...@dunslane.net) wrote: > First up, you guys should be aware that Greg Smith at least is > working on this. Let's not duplicate effort. Indeed. I'm also interested in making this happen and have worked with Greg in the past on it. There's even some code out there that we de

Re: [HACKERS] performance-test farm

Guys, There are two mutually exclusive problems to solve with a performance-test farm. The first problem is plaform performance, which would be a matter of expanding the buildfarm to include a small set of performance tests ... probably ones based on previously known problems, plus some other sim

  1   2   >