Re: [HACKERS] unicode questions

On Dec 24, 2009, at 4:14 PM, Andrew Dunstan wrote: 2) How far is normalization support in PG? When I checked a long time ago, there was no such support. Now that the SQL standard mandates a NORMALIZE function that may have changed. Any updates? > > Creating such a function sho

Re: [HACKERS] creating index names automatically?

On Dec 22, 2009, at 7:31 PM, Tom Lane wrote: > Wait a minute. I must have been looking at the wrong keyword list > --- ON already is reserved. The problem is exactly that it can't > tell whether CREATE INDEX CONCURRENTLY ON ... means to default the > index name or to create an index named CONCUR

Re: [HACKERS] alpha3 release schedule?

On Dec 22, 2009, at 11:02 AM, Simon Riggs wrote: > I've clearly been working too hard and will retire for some rest (even > though that is not listed as a task on the Wiki). Someone add it! David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subs

Re: [HACKERS] Segfault from PL/Perl Returning vstring

On Dec 21, 2009, at 9:04 PM, Andrew Dunstan wrote: > I cannot reproduce this. I tested with perl 5.10.1 which is the latest > reported stable release at , on an 8.4.2 > UTF8 database, and with the same Safe and Encode module versions as above. I've replicat

Re: [HACKERS] Segfault from PL/Perl Returning vstring

On Dec 21, 2009, at 2:34 PM, David E. Wheeler wrote: > On Dec 21, 2009, at 2:13 PM, Tim Bunce wrote: > >> You're using 5.8.8. In 5.10.0 $^V was changed to be an object. >> >> I'm working in that area. I'll look into it. > > While you're at i

Re: [HACKERS] Segfault from PL/Perl Returning vstring

On Dec 21, 2009, at 2:13 PM, Tim Bunce wrote: > You're using 5.8.8. In 5.10.0 $^V was changed to be an object. > > I'm working in that area. I'll look into it. While you're at it, I have a new problem: CREATE OR REPLACE FUNCTION wtf( expression text ) RETURNS text LANGUAGE plpe

Re: [HACKERS] Segfault from PL/Perl Returning vstring

On Dec 21, 2009, at 11:46 AM, Andrew Dunstan wrote: > It's not doing that for me. Odd. > The plperl code has no way at all of knowing that the bytes you are returning > come from $^V. If you really want the version back, do what the perl docs > tell you and sprintf the value: It works fine if

[HACKERS] Segfault from PL/Perl Returning vstring

At least I think it's a segfault. This function returns a vstring: CREATE OR REPLACE FUNCTION wtf( ) RETURNS text LANGUAGE plperl IMMUTABLE STRICT AS $X$ return $^V; $X$; Here's what happens when I call it: try=# select wtf(); server closed the connection unexpectedly This probably m

Re: [HACKERS] Minimum perl version supported

On Dec 21, 2009, at 7:18 AM, Tim Bunce wrote: >> Given the above three things it seems like we could define 5.8.1 as the >> minimum required version. > > I'd be delighted with that. +1 BTW Tim, have you tested with 5.11 yet? Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@

Re: [HACKERS] PATCH: Add hstore_to_json()

On Dec 18, 2009, at 8:51 AM, Robert Haas wrote: > What would that do for us? > > I'm not opposed to it, but it seems like the more important thing > would be to provide functions or operators that can do things like > extract an array, extract a hash key, identify whether something is a > hash, l

Re: [HACKERS] PATCH: Add hstore_to_json()

On Dec 18, 2009, at 4:49 AM, Peter Eisentraut wrote: > Should we create a json type before adding all kinds of json formatted > data? Or are we content with json as text? json_data_type++ D -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscript

Re: [HACKERS] PATCH: Add hstore_to_json()

On Dec 16, 2009, at 2:45 PM, Robert Haas wrote: > I like it. The regression tests you've added seem to cover a lot of > cases that aren't really different without covering some that are > probably worth trying, like multiple key/value pairs. Also, the > comment in the function you've added looks

Re: [HACKERS] Does "verbose" Need to be Reserved?

On Dec 16, 2009, at 2:29 PM, Tom Lane wrote: >> Looking at it more closely, this is likely to be fallout from the >> plpgsql lexer/parser changes; it probably worked before only because >> plpgsql was doing its own thing rather than using the main lexer. > > Hmm .. yeah, words that are reserved a

[HACKERS] Does "verbose" Need to be Reserved?

Hey All, I was just getting a new version of pgTAP ready for release, and while testing it on HEAD, I got this error: + psql:pgtap.sql:5789: ERROR: syntax error at end of input + LINE 28: IF verbose THEN RETURN NEXT diag(tests[i] ||... +^ I a

[HACKERS] PATCH: Spurious "22" in hstore.sgml

*** a/doc/src/sgml/hstore.sgml --- b/doc/src/sgml/hstore.sgml *** *** 278,284 get hstore's keys as a set skeys('a=>1,b=>2') ! 22 a b --- 278,284 get hstore's keys as a set skeys('a=>1,b=>2') ! a b -- Sent via

[HACKERS] PATCH: Add hstore_to_json()

I just realized that this was easy to do, and despite my complete lack of C skillz was able to throw this together in a couple of hours. It might be handy to some, though the possible downsides are: * No json_to_hstore(). * Leads to requests for hstore_to_yaml(), hstore_to_xml(), etc. * Andrew G

Re: [HACKERS] YAML Was: CommitFest status/management

On Dec 7, 2009, at 9:52 AM, Alvaro Herrera wrote: >> Tallying up the votes on this patch, we have Tom Lane, Andrew Dunstan, >> Josh Drake, and myself arguing against including this in core, and >> Josh Berkus and Itagaki Takahiro arguing for it. Ron Mayer seemed >> somewhat in favor of it in his

Re: [HACKERS] First feature patch for plperl - draft [PATCH]

On Dec 4, 2009, at 11:40 AM, Tim Bunce wrote: > Robert's comparison with mod_perl is very apt. Preloading code gives > dramatic performance gains in production situations where there's a > significant codebase and connections are frequent. > > The docs for plperl.on_perl_init could include a sect

Re: [HACKERS] First feature patch for plperl - draft [PATCH]

On Dec 4, 2009, at 11:05 AM, Tom Lane wrote: >> So, do we look for another way to provide the functionality besides >> having a GUC, or is the functionality itself bad? > > I don't think we want random Perl code running inside the postmaster, > no matter what the API to cause it is. I might hold

Re: [HACKERS] First feature patch for plperl - draft [PATCH]

On Dec 4, 2009, at 10:51 AM, Tom Lane wrote: >>plperl.on_perl_init = 'use PGInit;' > > No, you missed the point: I'm objecting to having any such thing as > plperl.on_perl_init, full stop. > > Aside from the points I already made, it's not even well defined. > What is to happen if the admin

Re: [HACKERS] First feature patch for plperl - draft [PATCH]

On Dec 4, 2009, at 10:36 AM, Tom Lane wrote: >> Are multiline GUCs allowed in the postgresql.conf file? > > I don't think so. In any case this seems like an extreme abuse of the > concept of a GUC, as well as being a solution in search of a problem, > as well as being something that should absol

Re: [HACKERS] First feature patch for plperl - draft [PATCH]

On Dec 4, 2009, at 3:18 AM, Tim Bunce wrote: > The perl code in plperl.on_perl_init gets eval'd as soon as an > interpreter is created. That could be at server startup if > shared_preload_libraries is used. plperl.on_perl_init can only be set by > an admin (PGC_SUSET). Are multiline GUCs allowed

Re: [HACKERS] operator exclusion constraints

On Dec 3, 2009, at 6:26 PM, Robert Haas wrote: > Yeah, I don't remember any such consensus either, but it's not a dumb > name. I have been idly wondering throughout this process whether we > should try to pick a name that conveys the fact that these constraints > are inextricably tied to the opcl

[HACKERS] Format Typmod?

Hey Hackers, I just had reason to want the way that format_type converts type names (e.g., varchar => character varying) in pgTAP, but didn't want the namespace qualification (used by format_type() when the type in question is not visible). I figured out that I could get that conversion by simp

Re: [HACKERS] First feature patch for plperl - draft [PATCH]

On Dec 3, 2009, at 3:30 PM, Tim Bunce wrote: > - New GUC plperl.on_perl_init='...perl...' for admin use. > - New GUC plperl.on_trusted_init='...perl...' for plperl user use. > - New GUC plperl.on_untrusted_init='...perl...' for plperlu user use. Since there is no documentation yet, how do these w

Re: [HACKERS] CommitFest status/management

On Nov 30, 2009, at 8:08 PM, Tom Lane wrote: >> I'm going to look at the YAML format for EXPLAIN patch shortly. > > Do we have consensus yet that we want YAML? It seemed, well, > yet another format without all that much advantage over what's > there. Legibility++ David -- Sent via pgsql-hack

Re: [HACKERS] [PATCH] hstore documentation update

On Dec 1, 2009, at 3:01 AM, David E. Wheeler wrote: On Dec 1, 2009, at 2:56 AM, Bruce Momjian wrote: Applied. Thanks. Thanks, I'll remove it from the next CF list, then. Oh, you already marked it as committed. Thanks! David -- Sent via pgsql-hackers mailing list (pgsql-ha

Re: [HACKERS] [PATCH] hstore documentation update

On Dec 1, 2009, at 2:56 AM, Bruce Momjian wrote: Applied. Thanks. Thanks, I'll remove it from the next CF list, then. Best, David -- 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] Timezones (in 8.5?)

On Nov 28, 2009, at 5:40 PM, Bruce Momjian wrote: > I think there is general agreement that we should have a timezone data > type which validates against pg_timezone_names().name. It might be > enough to just document how users can create such a domain data type, > but I don't know of a way to do

Re: [HACKERS] Ignoring white space in regression tests really a good idea?

On Nov 22, 2009, at 7:49 AM, Tom Lane wrote: > I'm thinking maybe we should remove -w. Comments? Have you tried it on the existing tests to see what happens? David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql

[HACKERS] [PATCH] hstore documentation update

From: David E. Wheeler As I threatened when I reviewed hstore in the last two commit fests, I've finally seen may way to edit the documentation. This is mostly word-smithing, making sure that all `>`s are encoded, making sure that various text is properly tagged with `` and `` tags,

Re: [HACKERS] plperl and inline functions -- first draft

On Nov 20, 2009, at 10:50 PM, Tim Bunce wrote: > I'd suggest: > >...; PL/Perl functions created with CREATE FUNCTION are called in a >scalar context, so can't return a list. You can return more complex >structures (arrays, records, and sets) by returning a reference, as >discusse

Re: [HACKERS] next CommitFest

On Nov 17, 2009, at 9:15 AM, Andrew Dunstan wrote: > Indeed. I once suggested only half jokingly that we should have a "Coder of > the month" award. I suggest that it be named "The Tom Lane" award, and disqualify Tom from winning (sorry Tom). ;-) David -- Sent via pgsql-hackers mailing list (

Re: [HACKERS] Summary and Plan for Hot Standby

On Nov 15, 2009, at 2:17 PM, Tom Lane wrote: >> So I'm in favor of committing part of the HS code even if there are >> known failure conditions, as long as those conditions are well-defined. > > If we're thinking of committing something that is known broken, I would > want to have a clearly defin

Re: [HACKERS] named parameters in SQL functions

On Nov 15, 2009, at 12:09 PM, Greg Stark wrote: > 1) Error messages which mention column names are supposed to quote the > column name to set it apart from the error string. This also > guarantees that weird column names are referenced correctly as "foo > bar" or "$foo" so the reference in the err

Re: [HACKERS] named parameters in SQL functions

On Nov 15, 2009, at 11:35 AM, Greg Stark wrote: > I don't think SQL is the height of language design either. But trying > to turn it into another language piece by piece is not gong to make it > any nicer. I don't know of anyone suggesting such a thing. > A sigil here doesn't accomplish anything

Re: [HACKERS] named parameters in SQL functions

On Nov 15, 2009, at 11:21 AM, Greg Stark wrote: > No, that's not the same. > > The point is that $ is a perfectly valid SQL identifier character and > $foo is a perfectly valid identifier. You can always quote any > identifier (yes, after case smashing) so you would expect if $foo is a > valid id

Re: [HACKERS] named parameters in SQL functions

On Nov 15, 2009, at 10:54 AM, Greg Stark wrote: > I'm japh too -- but that doesn't mean grabbing one little aesthetic > from Perl without copying the whole concept behind it makes any sense. > Perl sigils are an important part of the language and are a basic part > of the syntax. They aren't just

Re: [HACKERS] named parameters in SQL functions

On Nov 15, 2009, at 10:19 AM, Greg Stark wrote: >> I like the special marker idea. A '$' would be nice because its already in >> use for similar purposes, but I think that would lead to ambiguity with >> dollar quoting. > > I think that would be a big break with everything else and very > non-sq

Re: [HACKERS] operator exclusion constraints

On Nov 14, 2009, at 8:55 AM, Tom Lane wrote: >> I've been meaning to comment on this syntax one more time; apologies for the >> bike-shedding. But I'm wondering if the "CHECK" is strictly necessary there, >> since the WITH seems adequate, and there was some discussion before about >> the CHECK

Re: [HACKERS] operator exclusion constraints

On Nov 13, 2009, at 8:39 PM, Robert Haas wrote: > alter table foo add constraint bar exclude (a check with =, b check with =); I've been meaning to comment on this syntax one more time; apologies for the bike-shedding. But I'm wondering if the "CHECK" is strictly necessary there, since the WITH

Re: [HACKERS] array_to_string bug?

On Nov 12, 2009, at 10:46 AM, David Fetter wrote: > My question boils down to, "why is this string concatenation different > from all other string concatenations?" Does it have something to do with afikoman? David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make ch

Re: [HACKERS] operator exclusion constraints

On Nov 8, 2009, at 7:43 PM, Jeff Davis wrote: Either of those names are fine with me, too. The current name is a somewhat shortened version of the name "operator-based exclusion constraints", so we can also just use that name. Or, just "exclusion constraints". (exclusion constraints)++ David

Re: [HACKERS] operator exclusion constraints

On Nov 7, 2009, at 11:08 AM, Tom Lane wrote: EXCLUDE probably flows most nicely with the optional USING clause or without. My only complaint was that it's a transitive verb, so it seems to impart more meaning than it actually can. I doubt anyone would actually be more confused in practice, th

Re: [HACKERS] operator exclusion constraints

On Nov 5, 2009, at 11:09 AM, Jeff Davis wrote: I think EXCLUDING conflicts with the EXCLUDING in LIKE. Also, it becomes a little more difficult to place the access method clause, because "EXCLUDING USING gist" doesn't sound great. Well that's clearly a verb. So perhaps "EXCLUDE USING gist"

Re: [HACKERS] Shall we just get rid of plpgsql's RENAME?

On Nov 4, 2009, at 5:34 PM, Tom Lane wrote: According to http://developer.postgresql.org/pgdocs/postgres/plpgsql-declarations.html#PLPGSQL-DECLARATION-RENAMING-VARS the RENAME declaration in plpgsql has been known broken since PG 7.3. Nobody has bothered to fix it. Shall we just rip it out? +

Re: [HACKERS] EOL for 7.4?

On Nov 3, 2009, at 10:32 AM, Josh Berkus wrote: So I'm going to make a case in favor of EOL'ing 7.4. In fact, I'd be in favor of doing so in, say, February after an announcement this month +1 And, frankly, I think that we still need a published deprecation policy -- or at least a set of

Re: [HACKERS] Anonymous Code Blocks as Lambdas?

On Oct 26, 2009, at 2:12 PM, Pavel Stehule wrote: it should be light relation. 'DO' should be parametrised, and psql can use own variables as 'DO' parameters. I see, because `DO` is a statement, not an expression. Thus arguments don't really make much sense (I wish it was an expression!).

Re: [HACKERS] Anonymous Code Blocks as Lambdas?

On Oct 26, 2009, at 1:21 PM, Tom Lane wrote: A lambda facility would require being able to pass arguments and return results, which we intentionally left out of DO to keep it simple. By the time you add all that notation, it's far from clear that you shouldn't just define a function. Well s

Re: [HACKERS] Anonymous Code Blocks as Lambdas?

On Oct 26, 2009, at 1:16 PM, Pavel Stehule wrote: I have a idea about migration of outer (psql) variables, and custom shell variables. some like: psql --allow_custom_variables --table_name=mytable inside psql we should to use :table_name variable with "mytable" as content. then we can us

[HACKERS] Anonymous Code Blocks as Lambdas?

Howdy, Very excited about the new `DO` command in 8.5a2. I read through the patch review thread and found that, like me, Dim had expected it to behave more like a lambda than a simple command. And from Tom's comments, it looks like it was committed in such a way to make such extensions po

[HACKERS] Anonymous Code Blocks as Lambdas?

Howdy, Very excited about the new `DO` command in 8.5a2. I read through the patch review thread and found that, like me, Dim had expected it to behave more like a lambda than a simple command. And from Tom's comments, it looks like it was committed in such a way to make such extensions po

Re: [HACKERS] [ANNOUNCE] PostgreSQL 8.5alpha2 Now Available

On Oct 24, 2009, at 10:44 AM, Peter Eisentraut wrote: More detail is available in the Release Notes included with each alpha: http://developer.postgresql.org/pgdocs/postgres/release-8.5.html That seems to just have alpha1 at the moment. Best, David -- Sent via pgsql-hackers mailing list (

Re: [HACKERS] Controlling changes in plpgsql variable resolution

On Oct 21, 2009, at 11:37 AM, Robert Haas wrote: That's like saying that it's less of a risk than a group of rabid tyrannosaurs in a kindergarten classroom. I'm not sure, but I kind of doubt that tyrannosaurs can get rabies. I mean, if they were even around anymore. Which, you know, they're

Re: [HACKERS] Could regexp_matches be immutable?

On Oct 21, 2009, at 9:48 AM, Tom Lane wrote: I was wondering whether you could query pg_proc to look for functions with the same name and different arguments/results. It's a bit tricky though because you'd expect s/citext/text/ in at least some positions (maybe not all)? Yeah, almost all. I'l

Re: [HACKERS] Could regexp_matches be immutable?

On Oct 21, 2009, at 9:40 AM, David E. Wheeler wrote: On Oct 21, 2009, at 9:37 AM, Tom Lane wrote: Ooh, yeah, dunno how I missed that. I think we're probably stuck in 8.4, but we should fix it going forward. Would you make a quick check if any of the other citext functions have the sam

Re: [HACKERS] Could regexp_matches be immutable?

On Oct 21, 2009, at 9:37 AM, Tom Lane wrote: Ooh, yeah, dunno how I missed that. I think we're probably stuck in 8.4, but we should fix it going forward. Would you make a quick check if any of the other citext functions have the same bug? I've fixed it in my [version for 8.3](https://svn.ki

Re: [HACKERS] Could regexp_matches be immutable?

On Oct 21, 2009, at 7:27 AM, Tom Lane wrote: Huh, it looks to me like that's an error in the declaration of the citext versions of regexp_matches --- they should be declared to return setof text[], the same as the underlying text functions. David, do you agree? Ooh, yeah, dunno how I mis

Re: [HACKERS] Controlling changes in plpgsql variable resolution

On Oct 19, 2009, at 12:23 PM, Tom Lane wrote: That is, the specification of options is made outside of the language in question. I don't think I particularly care for this. It's inventing a global mechanism to cover a problem that we currently have one instance of in one PL. That's a mighty

Re: [HACKERS] Controlling changes in plpgsql variable resolution

On Oct 19, 2009, at 12:05 PM, Tom Lane wrote: What about adopting the modifier syntax you're adding to COPY? Where exactly would you put the modifier, and why is that better than the existing #option convention? CREATE OR REPLACE FUNCTION foo() RETURNS BOOLEAN LANGUAGE plpgsql WITH opt1, opt

Re: [HACKERS] Controlling changes in plpgsql variable resolution

On Oct 19, 2009, at 11:47 AM, Tom Lane wrote: 1. Invent a GUC that has the settings backwards-compatible, oracle-compatible, throw-error (exact spellings TBD). Factory default, at least for a few releases, will be throw-error. Make it SUSET so that unprivileged users can't break things by

Re: [HACKERS] Controlling changes in plpgsql variable resolution

On Oct 19, 2009, at 9:49 AM, Tom Lane wrote: I'd sure love $, as it's like shell, Perl, and other stuff. This discussion has gotten utterly off track. The problem I am trying to solve is a non-Oracle-compatible behavior in plpgsql. I have got substantially less than zero interest in proposal

Re: [HACKERS] Controlling changes in plpgsql variable resolution

On Oct 19, 2009, at 9:29 AM, Stephen Frost wrote: Uh, what dollar quoting? $_$ is what I typically use, so I wouldn't expect a $ prefix to cause a problem. I think it'd be more of an issue because pl/pgsql still uses $1 and whatnot internally (doesn't it?). Yes, but that's no more an issu

Re: [HACKERS] Controlling changes in plpgsql variable resolution

On Oct 19, 2009, at 8:36 AM, Robert Haas wrote: I think warnings are too easy to miss, but I agree your other suggestion. I know you can write function_name.variable_name, but that's often massively long-winded. We either need a short, fixed prefix, or some kind of sigil. I previously suggest

Re: [HACKERS] Controlling changes in plpgsql variable resolution

On Oct 19, 2009, at 7:54 AM, Stephen Frost wrote: 4. Resolve ambiguous names as query column, but throw warning #4 would be my vote, followed by #3. To be perfectly honest, I'd be a whole lot happier with a pl/pgsql that let me prefix variable names with a '$' or similar to get away from th

Re: [HACKERS] CommitFest 2009-09: how do we close this one out?

On Oct 10, 2009, at 7:55 PM, Robert Haas wrote: After some thought and reflection, I'm inclined to suggest that on 10/15 we move all the remaining patches to the next CommitFest, declare this one closed, and stamp alpha2 on schedule. +1, FWIW. David -- Sent via pgsql-hackers mailing list (pg

Re: [HACKERS] Issues for named/mixed function notation patch

On Oct 8, 2009, at 9:47 AM, Jeff Davis wrote: It's just the call notation -- the function only needs to know what arguments it got for which parameters. So they're still ordered? I'm thinking of PL/Perl here… David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Issues for named/mixed function notation patch

On Oct 7, 2009, at 9:00 PM, Steve Prentice wrote: Committed with a fair amount of corner-case cleanup and refactoring. Woot! Thanks for all the hard work getting this committed (Pavel, Bernd, Jeff, Tom and others)! I've been really looking forward to this feature. Still hoping a solution i

Re: [HACKERS] Concurrency testing

On Oct 7, 2009, at 5:18 PM, Jeff Janes wrote: I'd much rather live without Test::More and use DBD::Pg, then have Test::More but need to open pipes to psql to talk to the database, rather than using DBI to do it. But I guess we would need to worry about whether we can make DBD::Pg work with the

Re: [HACKERS] Concurrency testing

On Oct 7, 2009, at 10:38 AM, David Fetter wrote: When did Test::More become core? I believe we support back to Perl 5.6 :/ Module::CoreList says 5.006002, though I would have sworn it was added much earlier than that. You could always use Test.pm, I suppose, which has been in core since 5

Re: [HACKERS] Concurrency testing

On Oct 7, 2009, at 9:53 AM, David Fetter wrote: At the moment, we have no way to test this, although with certain Perl modules, it would be pretty trivial. No non-core modules necessary. Just use Test::More and file handles opened via pipes to two or more psql sessions. Best, David -- Se

Re: [HACKERS] Feature Suggestion: PL/Js

On Oct 7, 2009, at 7:55 AM, Andrew Dunstan wrote: BTW I've seen requests for PL/Js so I'm sure it'll be welcome. What license is v8 under? It's a BSD license, but it's a C++ API. While it looks cool, I think SpiderMonkey is possibly a better bet. SquirrelFish? http://webkit.org/blog/189/a

Re: [HACKERS] Rules: A Modest Proposal

On Oct 4, 2009, at 1:57 PM, David Fetter wrote: It's less about like or dislike and more about facing up to the reality that we've got a major legacy foot-gun left over from the experimentation of the Berkeley days. I think you're going to need to be a bit more concrete than that. In what wa

Re: [HACKERS] latest hstore patch

On Oct 2, 2009, at 11:14 AM, Bruce Momjian wrote: Well, if it is just changed syntax, we could wack around the system catalogs. If storage changes, we have to dump/reload that data type. Andrew solved this problem for hstore by making the new version able to read the old representation. It

Re: [HACKERS] latest hstore patch

On Oct 2, 2009, at 10:04 AM, Alvaro Herrera wrote: The point is it's *not* solved in the context of using pg_migrator. Yes, that's my point too, against David's argument that "surely someone must have solved it". What we have here is a new problem, so it's not so clear that there's any sol

Re: [HACKERS] latest hstore patch

On Oct 2, 2009, at 9:43 AM, Alvaro Herrera wrote: Plus lots of stuff on pgFoundry. It's a problem that needs to be solved. Surely someone, somewhere, has solved this problem, no? Dump & reload? Hahahahaha. No, really. "Dump & reload" is a phrase that end users will not put up with for much

Re: [HACKERS] CREATE OR REPLACE FUNCTION vs ownership

On Oct 2, 2009, at 8:49 AM, Tom Lane wrote: The ideal is that backends will start using the new function implementation on the next call after the REPLACE commits (but any evaluations already in progress must of course continue with the text they have). We have been gradually getting closer to

Re: [HACKERS] latest hstore patch

On Oct 2, 2009, at 8:20 AM, Bruce Momjian wrote: Most modules just install functions, which are easily uninstalled/reinstalled. A data type like hstore is more complicated assuming it is the data type that is changing and not the support functions. Lots of modules install data types. From con

Re: [HACKERS] CREATE OR REPLACE FUNCTION vs ownership

On Oct 2, 2009, at 7:49 AM, Tom Lane wrote: But in fact CREATE OR REPLACE is *not* meant to be the same as DROP followed by CREATE. What it is meant to do is allow you to replace the implementation of the function while existing callers see it as still being the same function. Thus we preve

Re: [HACKERS] CREATE OR REPLACE FUNCTION vs ownership

On Oct 1, 2009, at 3:42 PM, Tom Lane wrote: My inclination is to think that the right behavior for REPLACE FUNCTION is to keep the old proowner and proacl values, because that's what it always has done and nobody's complained. But I suppose a case could be made that you're completely replacin

Re: [HACKERS] navigation menu for documents

On Oct 1, 2009, at 1:12 AM, Richard Huxton wrote: Why wouldn't the entire TOC be in a collapsed list? Permanently on-screen? My only concern there would be for people viewing on phones etc. I have to admit that I'm never looking at the Pg docs on my iPhone. This is mainly because I use

Re: [HACKERS] latest hstore patch

On Sep 30, 2009, at 12:52 PM, Tom Lane wrote: Applied with some mostly-cosmetic editorialization. And there was much rejoicing… David -- 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] latest hstore patch

On Sep 29, 2009, at 5:00 PM, Andrew Gierth wrote: David> Sure. But I realized that I forgot to ask for David> array_to_hstore() and matrix_to_hstore(). :-) Would love to David> have those, too. Not sure about the operators… hstore(text[]) (which is also present as an explicit cast) covers both

Re: [HACKERS] latest hstore patch

On Sep 29, 2009, at 4:11 PM, Andrew Gierth wrote: I don't feel particularly strongly about the name (I've also intentionally held off on updating the pgfoundry version of the code until this is settled so no-one else should care either). I'm down with hstore_to_array() and hstore_to_matrix().

Re: [HACKERS] navigation menu for documents

On Sep 29, 2009, at 8:55 AM, Richard Huxton wrote: For the browser, does the following match what you're after, Andrew? - clicking chapter title opens the browser panel - panel stays open until you click close icon - panel contains collapsable tree of chapter/section headings Alternatively, coul

Re: [HACKERS] Hot Standby on git

On Sep 26, 2009, at 12:33 PM, Josh Berkus wrote: There's always pgtap. Whenever we find a new corner case, we add it to the development test suite. Also, for C TAP, there's [libtap](http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap ). You can then use `prove` which you likely already have

Re: [HACKERS] latest hstore patch

On Sep 23, 2009, at 5:27 PM, Andrew Gierth wrote: I intentionally avoided hstore_to_array because it would be unclear which one it meant (the 1-d or 2-d result). Thanks Andrew. Given these replies, unless anyone else wants to weigh in on the array conversion operator and function names, thi

Re: [HACKERS] Unicode Normalization

On Sep 24, 2009, at 8:59 AM, Andrew Dunstan wrote: That might be nice, but I'd be wary of a geometric multiplication of text types. We already have TEXT and CITEXT; what if we had your NTEXT (normalized text) but I wanted it to also be case-insensitive? Actually, I don't think it's necessar

Re: [HACKERS] Unicode Normalization

On Sep 24, 2009, at 6:24 AM, p...@thetdh.com wrote: In a context using normalization, wouldn't you typically want to store a normalized-text type that could perhaps (depending on locale) take advantage of simpler, more-efficient comparison functions? That might be nice, but I'd be wary of

Re: [HACKERS] latest hstore patch

On Sep 22, 2009, at 7:18 PM, Andrew Gierth wrote: Hstore patch incorporating changes as previously discussed. In addition the requested new features of conversions to and from array formats have been added (with docs). Thanks Andrew. Just a few thoughts for discussion: * From my previous po

Re: [HACKERS] Unicode Normalization

On Sep 23, 2009, at 11:08 AM, David E. Wheeler wrote: I looked around and found the Public Software Group's utf8proc project, which even includes some PostgreSQL support (not, alas, for normalization). It has an MIT-licensed C library that offers these functions: Sorry, forgot the

Re: [HACKERS] Unicode Normalization

On Sep 23, 2009, at 11:08 AM, David E. Wheeler wrote: I just had a discussion on IRC about unicode normalization in PostgreSQL. Apparently there is not support for it, currently. BTW, the only reference I found on the [to do list](http://wiki.postgresql.org/wiki/Todo ) was: More sensible

[HACKERS] Unicode Normalization

Hackers, I just had a discussion on IRC about unicode normalization in PostgreSQL. Apparently there is not support for it, currently. Andrew Gierth points out that it's part of the SQL spec to support it, though: RhodiumToad:e.g. NORMALIZE(foo,NFC,len) justatheory:Oh, just a function then

Re: [HACKERS] updated hstore patch

On Sep 21, 2009, at 4:57 PM, Andrew Gierth wrote: I don't think there's any way to do that from the regression tests. The output that you demonstrated a few messages back should do nicely for delete(), at least: contrib_regression=# explain verbose select delete(('a' => now()::text),'a')

Re: [HACKERS] updated hstore patch

On Sep 20, 2009, at 12:15 PM, Tom Lane wrote: That recipe doesn't actually work for cases like this. What *would* work is loading the module *before* restoring from your old dump, then relying on the CREATEs from the incoming dump to fail. Jesus this is hacky, either way. :-( I believe we h

Re: [HACKERS] updated hstore patch

On Sep 20, 2009, at 3:14 PM, Andrew Gierth wrote: I think you're missing the point here; I can't control what it resolves to, since that's the job of the function overload resolution code. Yeah, but I think that the existing behavior is probably the best. But I checked, and delete(hstore,$

Re: [HACKERS] updated hstore patch

On Sep 20, 2009, at 8:43 AM, Tom Lane wrote: If the perfect solution is too complex, I'd also kinda hope this isn't a show-stopper for this patch, but rather a TODO for the future modules feature. Yeah, this is a long-standing generic issue, and not really hstore's problem to fix. So then

Re: [HACKERS] updated hstore patch

On Sep 20, 2009, at 1:03 AM, Andrew Gierth wrote: I will resubmit (hopefully in a day or two) with the following changes: - removal of the \set schema variable stuff from the .sql script - documentation fixes as mentioned in my previous email - additional documentation for some of the newer f

Re: [HACKERS] updated hstore patch

On Sep 18, 2009, at 6:27 PM, Andrew Gierth wrote: However, I would prefer to keep the ability to do this: psql --set hstore_schema='myschema' -f hstore.sql dbname The logic to do it is a bit ugly, but editing the file to set what schema to use is even uglier... Yes, this should perhaps be

Re: [HACKERS] updated hstore patch

On Sep 19, 2009, at 7:03 PM, Tom Lane wrote: Given the number of questions in your review, I don't think this is actually ready to commit. I'm marking it "waiting on author" instead. Yes, actually, I had second thoughts about that and meant to change it myself. Thanks Tom. David -- Sent

<    6   7   8   9   10   11   12   13   14   15   >