Re: [HACKERS] extensible enum types

Tom Lane wrote: And how would it be per data-type? Well, there'd be two kinds of enums, just as you were saying before. I'm not sure how we'd expose that to users exactly, or whether there could be provisions for switching a type's behavior after creation.

Re: [HACKERS] extensible enum types

Joseph Adams writes: > Couldn't enum_eq just use get_fn_expr_argtype to determine the type of > enum input rather than rely on it being stored in the value No. Support functions have to work in many contexts where there is no "side channel" such as get_fn_expr_argtype. What's more, it's very di

Re: [HACKERS] extensible enum types

Excerpts from Joseph Adams's message of vie jun 18 18:17:50 -0400 2010: > Couldn't enum_eq just use get_fn_expr_argtype to determine the type of > enum input rather than rely on it being stored in the value (either > implicitly via OID or explicitly as a word half)? > > Also, I can't seem to find

Re: [HACKERS] extensible enum types

Joseph Adams wrote: Also, I can't seem to find the original debates from when enums were implemented. Does anyone have a link to that thread in the archives? Thanks. Start here cheers andrew -- Sent via pgsql-hacker

Re: [HACKERS] extensible enum types

On Fri, Jun 18, 2010 at 1:59 PM, Andrew Dunstan wrote: > > > Robert Haas wrote: >> >> On Fri, Jun 18, 2010 at 12:59 PM, Andrew Dunstan >> wrote: >> >>> >>> You are just bumping up the storage cost. Part of the attraction of enums >>> is >>> their efficiency. >>> >> >> What's efficient about them?

Re: [HACKERS] hstore ==> and deprecate =>

On Fri, Jun 18, 2010 at 7:27 PM, David E. Wheeler wrote: > We don't have a slice operator for arrays; would we be happy with %> being > such an operator in a future version? And, does the spec say anything about > array operators? > Personally, I don't find any of these proposals terribly intui

Re: [HACKERS] About tapes

On Fri, Jun 18, 2010 at 3:46 PM, mac_man2...@hotmail.it wrote: > Which is the difference between having more than one tape into a file and > having one tape per file? It makes it easier to recycle space a little at a time. Suppose you're merging two runs of 100 blocks each. You read in a block

Re: [HACKERS] About tapes

Ok, so let's try asking the question in another way. Which is the difference between having more than one tape into a file and having one tape per file? I mean, we are peaking runs belonging to different tapes and merge those runs. Moreover, why space is reduced taking in account that we can

Re: [HACKERS] About tapes

Robert Haas writes: > On Fri, Jun 18, 2010 at 3:11 PM, mac_man2...@hotmail.it > wrote: >> I repeat my question. Tuplesort.c and logtape.c DO implement tapes on disk >> and currently they do not request 2x or 4x of the input space: so, again, in >> which case implementing tapes on disks requires b

Re: [HACKERS] extensible enum types

Andrew Dunstan writes: > Tom Lane wrote: >> Insert a sort order column into pg_enum, and rearrange the values in >> that whenever the user wants to add a new value in a particular place. >> You give up cheap comparisons in exchange for flexibility. I think lots >> of people would accept that trad

Re: [HACKERS] About tapes

On Fri, Jun 18, 2010 at 3:11 PM, mac_man2...@hotmail.it wrote: > Il 18/06/2010 21:00, Robert Haas ha scritto: >> >> On Fri, Jun 18 >> Did you read the rest of the comment?  It explains how the code avoids >> this... >> >> > > Robert, thanks for your reply. > I read the rest of the document, but pl

Re: [HACKERS] About tapes

Il 18/06/2010 21:00, Robert Haas ha scritto: On Fri, Jun 18 Did you read the rest of the comment? It explains how the code avoids this... Robert, thanks for your reply. I read the rest of the document, but please take in account that my question wasn't about "avoiding". My question is "

Re: [HACKERS] About tapes

On Fri, Jun 18, 2010 at 2:36 PM, mac_man2...@hotmail.it wrote: > Please take a look at the initial comment contained into the logtape.c file: > http://doxygen.postgresql.org/logtape_8c-source.html > > Almost at the beginning of that file, it is affirmed that implementing tapes > on disk (quote: by

[HACKERS] About tapes

Hi to all. Please take a look at the initial comment contained into the logtape.c file: http://doxygen.postgresql.org/logtape_8c-source.html Almost at the beginning of that file, it is affirmed that implementing tapes on disk (quote: /by creating a separate file for each "tape"/) will require

Re: [HACKERS] extensible enum types

On Fri, Jun 18, 2010 at 6:17 PM, Andrew Dunstan wrote: > > > Tom Lane wrote: >> >> Insert a sort order column into pg_enum, and rearrange the values in >> that whenever the user wants to add a new value in a particular place. +1 I was going to say exactly the same thing. >> You give up cheap com

Re: [HACKERS] hstore ==> and deprecate =>

On Jun 18, 2010, at 11:20 AM, Greg Stark wrote: >> +1 from me, too. >> > > 1 isn't a valid character in a postgres operator Dammit! This reminds me, I wanted to ask one more thing: We don't have a slice operator for arrays; would we be happy with %> being such an operator in a future version

Re: [HACKERS] hstore ==> and deprecate =>

On Fri, Jun 18, 2010 at 6:26 PM, David E. Wheeler wrote: > +1 from me, too. > 1 isn't a valid character in a postgres operator :P -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hacke

Re: [HACKERS] extensible enum types

On Fri, Jun 18, 2010 at 1:59 PM, Andrew Dunstan wrote: > This was debated when we implemented enums. As between 1,2 and 4 there is > often not much to choose, as alignment padding makes it pretty much the > same. But any of them are more efficient than storing a numeric value or the > label itsel

Re: [HACKERS] extensible enum types

Robert Haas wrote: On Fri, Jun 18, 2010 at 12:59 PM, Andrew Dunstan wrote: You are just bumping up the storage cost. Part of the attraction of enums is their efficiency. What's efficient about them? Aren't we using 4 bytes to store a value that will nearly always fit in 2, if not 1

Re: [HACKERS] hstore ==> and deprecate =>

On Jun 18, 2010, at 10:03 AM, Josh Berkus wrote: >> I'd vote for %>, out of those. Reason: the operator isn't commutative, >> in fact left and right inputs aren't even the same datatype, so a glyph >> that looks asymmetric seems more natural. > > +1 on %> +1 from me, too. Best, David -- Sen

Re: [HACKERS] extensible enum types

On Fri, Jun 18, 2010 at 12:59 PM, Andrew Dunstan wrote: > You are just bumping up the storage cost. Part of the attraction of enums is > their efficiency. What's efficient about them? Aren't we using 4 bytes to store a value that will nearly always fit in 2, if not 1? -- Robert Haas Enterprise

Re: [HACKERS] extensible enum types

Tom Lane wrote: Andrew Dunstan writes: Robert Haas wrote: I like the idea of being able to modify enums on the fly, but I'm skeptical of an implementation that won't always work. Maybe it's still better than what we have now, but it seems grotty. I'd be perfectly happy

Re: [HACKERS] hstore ==> and deprecate =>

I vote for % . I'd vote for %>, out of those. Reason: the operator isn't commutative, in fact left and right inputs aren't even the same datatype, so a glyph that looks asymmetric seems more natural. +1 on %> (Frankly, as long as it isn't & or | I can live with it ... ) --

Re: [HACKERS] extensible enum types

David E. Wheeler wrote: On Jun 18, 2010, at 9:34 AM, Andrew Dunstan wrote: I'd be perfectly happy to hear a reasonable alternative. Assuming we use some integer representation, given two labels represented by n and n+1, we can't add a label between them without rewriting the tables that

Re: [HACKERS] extensible enum types

David E. Wheeler wrote: What's the likelihood of a failure? Constructing a failure case would be simple. In practice, I suspect it would be very low. And would the position of the new label (represented by its internal number) be predictive? IOW, would updating the same varenumtype in tw

Re: [HACKERS] extensible enum types

Andrew Dunstan writes: > Robert Haas wrote: >> I like the idea of being able to modify enums on the fly, but I'm >> skeptical of an implementation that won't always work. Maybe it's >> still better than what we have now, but it seems grotty. > I'd be perfectly happy to hear a reasonable alternat

Re: [HACKERS] extensible enum types

On Fri, 2010-06-18 at 12:34 -0400, Andrew Dunstan wrote: > > Robert Haas wrote: > > On Fri, Jun 18, 2010 at 11:50 AM, Andrew Dunstan > > wrote: > > > >> Then set the > >> first value at 8 * p, then next at 9* p and so on. This is designed to > >> allow more space to add labels at the beginni

Re: [HACKERS] extensible enum types

On Jun 18, 2010, at 9:34 AM, Andrew Dunstan wrote: > I'd be perfectly happy to hear a reasonable alternative. Assuming we use some > integer representation, given two labels represented by n and n+1, we can't > add a label between them without rewriting the tables that use the type, > whether i

Re: [HACKERS] extensible enum types

On Jun 18, 2010, at 9:07 AM, Robert Haas wrote: >> Then set the >> first value at 8 * p, then next at 9* p and so on. This is designed to >> allow more space to add labels at the beginning and end of the list, where >> this is more likely. Adding a label would be a matter of finding the labels >>

Re: [HACKERS] extensible enum types

Robert Haas wrote: On Fri, Jun 18, 2010 at 11:50 AM, Andrew Dunstan wrote: Then set the first value at 8 * p, then next at 9* p and so on. This is designed to allow more space to add labels at the beginning and end of the list, where this is more likely. Adding a label would be a matter o

Re: [HACKERS] extensible enum types

On Fri, Jun 18, 2010 at 11:50 AM, Andrew Dunstan wrote: > Then set the > first value at  8 * p, then next at 9* p and so on. This is designed to > allow more space to add labels at the beginning and end of the list, where > this is more likely. Adding a label would be a matter of finding the label

[HACKERS] extensible enum types

A recent discussion with a developer convinced me that enums would be much more useful if new values could be added to the label list easily without changing the stored values. Given the current representation of enums as a globally unique oid, I think this is just about impossible if the new

Re: [HACKERS] system views for walsender activity

Heikki Linnakangas writes: > Let's discuss what the best possible user interface for the information > would be first, and then decide if we need/want to force an initdb for > that. We have pg_upgrade now, that makes initdb less painful, and if > it's just a new view it might be possible to jus

Re: [HACKERS] Debug message in RemoveOldXlogFiles

Simon Riggs writes: > I think it would be more helpful if it showed a filename. Shall we > change that? The point of the committed change was to make that message look like every other one in xlog.c that shows a log/seg pair. If we were going to start redesigning the printout format, I'd persona

Re: [HACKERS] system views for walsender activity

On 18/06/10 13:41, Simon Riggs wrote: On Fri, 2010-06-18 at 11:33 +0900, Takahiro Itagaki wrote: 1. Add another system view for walsenders, ex. "pg_stat_replication". It would show pid, remote host, and sent location for each walsender. I prefer this option. I consider it an omission that

Re: [HACKERS] system views for walsender activity

On Fri, 2010-06-18 at 11:33 +0900, Takahiro Itagaki wrote: > 1. Add another system view for walsenders, ex. "pg_stat_replication". >It would show pid, remote host, and sent location for each walsender. I prefer this option. I consider it an omission that we should correct. Not sure I underst

[HACKERS] Re: pg_dump does not honor namespaces when functions are used in index

On 18 June 2010 09:31, Jean-Baptiste Quenot wrote: > 2010/6/17 Greg Stark : > > On Thu, Jun 17, 2010 at 4:08 PM, Tom Lane wrote: > >>> I actually wonder if we shouldn't automatically tag plpgsql functions > >>> with the search_path in effect at the time of their creation (as if > >>> the user ha

Re: [HACKERS] debug log in pg_archivecleanup

On Thu, 2010-06-17 at 13:33 -0400, Tom Lane wrote: > Fujii Masao writes: > > On Wed, Jun 16, 2010 at 12:24 PM, Takahiro Itagaki > > wrote: > >> This is because pg_archivecleanup puts the line break "\n" in the head of > >> debug message. Why should we do so? > > > Yes. What about the attached pa

Re: [HACKERS] Debug message in RemoveOldXlogFiles

On Thu, 2010-06-17 at 16:13 +0900, Fujii Masao wrote: > Hi, > > In the following debug message in RemoveOldXlogFiles(), the variables > "log" and "seg" don't indicate LSN, so we should use %u instead of %X? > > elog(DEBUG2, "removing WAL segments older than %X/%X", log, seg); > > I attached

Re: [HACKERS] system views for walsender activity

On Fri, Jun 18, 2010 at 04:33, Takahiro Itagaki wrote: > Hi, > > We don't have any statistic views for walsenders in SR's master server > in 9.0, but such views would be useful to monitor and manage standby > servers from the master server. I have two ideas for the solution - > adding a new system

Re: [HACKERS] Explicit psqlrc

On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera wrote: > Excerpts from Mark Wong's message of mié jun 16 23:54:52 -0400 2010: > > > ==Usability review== > > Read what the patch is supposed to do, and consider: > > Does the patch actually implement that? > > How does it play with ON_ERROR_STOP/R

Re: [HACKERS] trace_recovery_messages

On Fri, 2010-06-18 at 10:20 +0900, Fujii Masao wrote: > On Fri, Jun 18, 2010 at 2:48 AM, Tom Lane wrote: > > Fujii Masao writes: > >> We should make trace_recovery_messages available only when > >> the WAL_DEBUG macro was defined? > > > > No, because it's used in a lot of other contexts besides t

[HACKERS] Re: pg_dump does not honor namespaces when functions are used in index

2010/6/17 Greg Stark : > On Thu, Jun 17, 2010 at 4:08 PM, Tom Lane wrote: >>> I actually wonder if we shouldn't automatically tag plpgsql functions >>> with the search_path in effect at the time of their creation (as if >>> the user had done ALTER FUNCTION ... SET search_path=...whatever the >>> c