On Feb 16, 2011, at 1:20 PM, Dimitri Fontaine wrote:
We will then need build-time requires (build-depends would say debian)
so that the system knows what's needed to run the install or upgrade
scripts. I've been thinking that's for 9.2, but maybe that would be a
simpler fix for you here.
On Feb 14, 2011, at 11:44 PM, Oleg Bartunov wrote:
IMO, sooner or later we need to trash that code and replace it with
something a bit more modification-friendly.
We thought about configurable parser, but AFAIR, we didn't get any support
for this at that time.
What would it take to change
On Feb 16, 2011, at 3:00 PM, Tom Lane wrote:
According to our prior discussions of C.O.R. commands, the general
principle that such a command ought to follow is that upon success,
the object exists with exactly the properties implied by the command's
arguments. So (1) if the extension isn't
On Feb 15, 2011, at 6:39 AM, Alexey Klyukin wrote:
After I re-added the closing /para in plperl.sgml:235 these errors
disappeared, and the
resulting html looks fine too. v10 with just this single change is attached.
So is this ready for committer?
Best,
David
--
Sent via pgsql-hackers
On Feb 15, 2011, at 9:49 AM, Alexey Klyukin wrote:
After I re-added the closing /para in plperl.sgml:235 these errors
disappeared, and the
resulting html looks fine too. v10 with just this single change is attached.
So is this ready for committer?
Yes.
Awesom, thanks Alexey Alex!
On Feb 15, 2011, at 12:32 PM, Tom Lane wrote:
Aside from the double-dash method, we kicked around using colons and
pluses as separators (and then forbidding just those characters in
extension and version names). Any of those would be workable, but it's
not clear to me that any of them have
On Feb 15, 2011, at 1:15 PM, Robert Haas wrote:
Yeah, that bug is fixed with the attached, though I am rethinking this
bit.
I am thinking that the statute of limitations has expired on this
patch, and that we should mark it Returned with Feedback and continue
working on it for 9.2. I know
On Feb 15, 2011, at 5:18 PM, Tom Lane wrote:
Currently, ALTER EXTENSION UPDATE throws an error if there's nothing to
do:
regression=# create extension adminpack ;
CREATE EXTENSION
regression=# alter extension adminpack update;
ERROR: version to install or update to must be different from
On Feb 14, 2011, at 8:54 AM, Tom Lane wrote:
I'm not convinced. There was nothing in that discussion why any
particular character would have to be allowed in a version number.
Well, there's already a counterexample in the current contrib stuff:
uuid-ossp. We could rename that to uuid_ossp
On Feb 14, 2011, at 9:14 AM, Tom Lane wrote:
Commas do not seem like an improvement to me at all --- they are widely
used as list separators.
Fair enough.
I guess the real question is what's Peter's concrete objection to the
double-dash method?
Hey, I know, a double-dash between the
Hackers,
Is it possible to modify the default tsearch parser so that / doesn't get lexed
as a file token? That is, instead of this:
try=# select * from ts_debug('simple'::regconfig, 'w/d');
alias │description│ token │ dictionaries │ dictionary │ lexemes
On Feb 14, 2011, at 5:03 PM, Tom Lane wrote:
Are we deparsing the names of the SQL files to infer the set of
version numbers we have to worry about? It seems to me that if
there's a list of known version numbers somewhere, we can use dash as
the separator without any special restricton.
On Feb 14, 2011, at 5:42 PM, Tom Lane wrote:
Remember also that not all modules out there on the net will have been
updated either, so we must be able to discuss extension-izing a
module. (??)
Right. So it seems like we ought to stick with more or less the
existing terminology: those
On Feb 14, 2011, at 3:57 PM, Tom Lane wrote:
There is zero, none, nada, provision for modifying the behavior of the
default parser, other than by changing its compiled-in state transition
tables.
It doesn't help any that said tables are baroquely designed and utterly
undocumented.
IMO,
On Feb 14, 2011, at 8:18 PM, Tom Lane wrote:
Yes, but the truth is that the extension name, at least, is known from the
control file.
Yeah, I think it's true in the current code base that we always know the
extension name we are interested in. However, that's no protection if
we allow
On Feb 14, 2011, at 11:37 PM, Oleg Bartunov wrote:
it's not easy to hack tsearch parser, sorry. You can preparse your input
before to_tsquery,to_tsvector.
Yeah, I was thinking about s{/}{-}g before passing the values in. Might be the
only way to do it for now…
Thanks,
David
--
Sent via
On Feb 13, 2011, at 11:34 AM, Tom Lane wrote:
OK, so with that, attached is an example of the complete conversion diff
for a contrib module (hstore in particular). Although git status
reports hstore--1.0.sql as being a rename of hstore.sql.in, git diff
doesn't seem to be exceedingly bright
On Feb 13, 2011, at 4:46 PM, Tom Lane wrote:
I sure would like it if the install script with no version in it
corresponded to the latest version. Otherwise, one must rename the file
every time one does a release. And as you're noting, you lose Git history
that way.
(1) git does know
On Feb 13, 2011, at 4:59 PM, Tom Lane wrote:
I think after a couple of releases you'd be shipping something like
foo--1.0.sql
foo--1.1.sql
foo--1.0--1.1.sql
foo--2.0.sql
foo--1.1--2.0.sql
and it'll soon get to be a mess if your SCM doesn't clearly
On Feb 12, 2011, at 2:29 PM, Tom Lane wrote:
I did think of another idea besides forbidding dash in extension names:
what if we use double dash as the name/version separator, ie the naming
conventions are like
extension--version.control
extension--version.sql
On Feb 12, 2011, at 3:12 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
On Feb 12, 2011, at 2:29 PM, Tom Lane wrote:
I did think of another idea besides forbidding dash in extension names:
what if we use double dash as the name/version separator,
+1 You might even
On Feb 12, 2011, at 3:37 PM, Tom Lane wrote:
How likely is *that*?
Not very, but the rules are getting a bit complicated ...
Doesn't seem complicated to me:
1. Use -- to separate extension name, old version, new version
2. Don't use - at the beginning or end of name or version number
3.
On Feb 10, 2011, at 11:43 PM, Alex Hunsaker wrote:
I'd like to quibble with you over this point if I may. :-)
Per perldoc: JSON::XS
utf8 flag disabled
When utf8 is disabled (the default), then
encode/decode generate and expect Unicode strings ...
So
- If you are on 9.1 and a
On Feb 11, 2011, at 9:44 AM, Alex Hunsaker wrote:
It is decoded... the input string %C3%A9 actually is the _same_
string utf-8, latin1 and SQL_ASCII decoded or not. Those are all ascii
characters. Calling utf8::decode(%C3%A9) is essentially a noop.
No, it's not decoded. It doesn't matter
On Feb 11, 2011, at 9:34 AM, Andrew Dunstan wrote:
Is there an action item here? Is the documentation inadequate or inaccurate?
If so, please make a suggestion for improved wording.
I certainly expect the change to be covered in the release notes. You can
check on the prominence given the
On Feb 11, 2011, at 10:01 AM, Alex Hunsaker wrote:
That *looks* like it is decoding the input string, which it is, but
actually that will double utf8 encode your string. It does not seem to
in this case because we are dealing with all ascii input. The trick
here is its also telling perl to
On Feb 11, 2011, at 10:06 AM, Tom Lane wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Hmm. To make that work, we'd have to have ALTER EXTENSION UPDATE use a
different default version name from what CREATE EXTENSION uses (unless
Yes. I see that
On Feb 11, 2011, at 9:35 AM, Tom Lane wrote:
OK, let me see if I can summarize what I think we've agreed to:
CREATE syntax is extended to
CREATE EXTENSION extname [WITH] [SCHEMA s] [VERSION v] [FROM oldv]
If VERSION is not specified, v is taken from default_version in the
control
On Feb 11, 2011, at 10:30 AM, Tom Lane wrote:
No --- in the current vision, a control file may describe a whole
collection of versions of the same extension, and the parameter in
question is selecting the default or preferred version to install.
I'm not wedded to default_version, but I think
On Feb 11, 2011, at 10:58 AM, Aidan Van Dyk wrote:
I release exetension afoo, initial as version 1.0. From my
understanding, it's going to contain:
afoo control file, named something particular)
- default_version = 1.0
- encoding utf8
foo-1.0.sql installstion script
and
On Feb 11, 2011, at 11:50 AM, Dimitri Fontaine wrote:
It would be good to avoid regexp and globing pattern characters, I would
say.
There's the coma, as in foo,1.0,1.1.sql, so ugly that it's unused :) I
wonder if : would be good? foo:1.0:1.1.sql. A very quick test seems
to show that
On Feb 11, 2011, at 10:28 AM, Josh Berkus wrote:
So, if we allow empty ranges of this kind, I would want a GUC for
allow_empty_ranges.
GUC you, josh. ;-P
D
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Feb 11, 2011, at 12:57 PM, Alex Hunsaker wrote:
Yay! 1
Yes, this is all good. But it still seems to me that:
* If your database is neither utf-8 no sql_ascii
* And your PL/Perl functions expect arguments that are byte soup
* Once you upgrade to 9.1 they won't be
* So you'll need to encode
On Feb 11, 2011, at 3:58 PM, Alex Hunsaker wrote:
You mean... we have been talking past each other this whole time?
Well, since my second post, I think. I was wrong in the first one.
Olegs case _was_ a utf8 database.
From his original bug:
Hi there, below is the problem, which I don't
On Feb 10, 2011, at 10:26 AM, Tom Lane wrote:
1. Choose the newest available version.
2. Let the control file specify which version is the default.
I think I prefer #2 because it avoids needing a rule for comparing
version identifiers, and it caters to the possibility that the
On Feb 10, 2011, at 11:31 AM, Tom Lane wrote:
I'm not really addressing that in this proposal. You could imagine
supporting all the extension versions in one .so, or you could have one
per version (meaning the upgrade scripts would have to CREATE OR REPLACE
all the C functions to re-point
On Feb 10, 2011, at 10:41 AM, Jeff Davis wrote:
This might solve the constructor problem nicely if we could do things
like:
RANGE[10,20)
But I have a feeling that will either cause a bizarre problem with the
grammar, or someone will think it's not very SQL-like.
I like it a lot better than
On Feb 10, 2011, at 11:21 AM, Tom Lane wrote:
It will certainly mess up syntax highlighting and matching bracket detection
in pretty much all text editors...
Yeah. It's a cute-looking notation but surely it will cause many more
problems than it's worth. I agree with Robert's suggestion of
On Feb 10, 2011, at 12:02 PM, Tom Lane wrote:
Oh, I see, you're just saying that it's not unlikely somebody could find
himself with dozens of minor releases all being supported. Yeah, he'd
then really need to provide shortcut upgrade scripts, and
building/maintaining those would be a pain.
On Feb 10, 2011, at 12:07 PM, Robert Haas wrote:
You don't need them to be sortable. You just need them to be
comparable, and equality seems like a plenty good enough comparison
rule. You can compute the shortest chain of upgrade scripts that can
take you from the current version to the
On Feb 10, 2011, at 1:22 PM, Tom Lane wrote:
Well, okay, let's go with that plan then. If we don't need to assume
anything more than equality of version names being meaningful, I think
chaining update scripts automatically should solve most of the
complaints here. People who really want to
On Feb 10, 2011, at 1:38 PM, Tom Lane wrote:
I don't deny that there are risks here. But I think the value of being
able to move an extension when it is safe outweighs the difficulty that
sometimes it isn't safe. I think we can leave making it safer as a
topic for future investigation.
Hackers,
With regard to this (very welcome) commit:
commit 50d89d422f9c68a52a6964e5468e8eb4f90b1d95
Author: Andrew Dunstan and...@dunslane.net
Date: Sun Feb 6 17:29:26 2011 -0500
Force strings passed to and from plperl to be in UTF8 encoding.
String are converted to UTF8
On Feb 10, 2011, at 3:50 PM, Tom Lane wrote:
It seems that we've mostly got consensus on the ideas of having a separate
script file for each installable version of an extension, and for each
basic version-upgrade action, with version numbers embedded in the file
names so that the control
On Feb 10, 2011, at 4:11 PM, Tom Lane wrote:
It's to tell it to create an empty extension in preparation for
absorbing pre-existing objects from an old-style contrib module.
See what I mean? WRAPPER is not a useful keyword here.
Reminds me of creating a shell type so you can create I/O
On Feb 10, 2011, at 5:28 PM, Alex Hunsaker wrote:
Hrm? For UTF-8 databases, in practice, nothing should have changed--
we already passed strings in as utf8. What I fixed was some corner
cases where some strings did not always have character semantics. See
The Unicode Bug and Forcing Unicode
On Feb 10, 2011, at 7:05 PM, Tom Lane wrote:
I like this because (a) it's one less step, and one less concept for
users to deal with, and (b) it's much harder to screw up. If you forget
FROM OLD when you needed it, the CREATE will fail with object already
exists errors. If you use FROM OLD
On Feb 10, 2011, at 9:15 PM, Tom Lane wrote:
Hmm, you're right. The word bootstrap implies that we're starting from
nothing, which is exactly what we're *not* doing (starting from nothing
is the easy clean install case). By the same token, FROM NOTHING
isn't the right phrase either. An
On Feb 9, 2011, at 9:20 AM, Robert Haas wrote:
There are certainly some patches in this CommitFest that need more
attention than that, and that probably need the attention of a senior
community member. Jeff's range types patch and Alvaro's key lock
patch are two of those. And I would be
On Feb 8, 2011, at 6:48 PM, Tom Lane wrote:
Like ALTER THING SET SCHEMA, ALTER THING SET EXTENSION is implicitly
assuming that there can be only one owning extension for an object.
Furthermore, it's not really intended for *removal* of an object from an
extension (a concept that doesn't even
On Feb 9, 2011, at 10:29 AM, Robert Haas wrote:
Frankly, I think you should surrender some of those 14 and cajole some other
folks to take on more.
Happily... only trouble is, I suck at cajoling. Even my begging is
distinctly sub-par.
Plase?
Try this:
“Listen up, bitches!
On Feb 9, 2011, at 10:56 AM, Robert Haas wrote:
“Listen up, bitches! I'm tired of Tom and me having to do all the work. All
of you who submitted patches need to review some other patches! If you
haven't submitted a review for someone else's patch by commitfest end, your
patches will be
On Feb 8, 2011, at 9:36 AM, Robert Haas wrote:
I guess I'm sort of coming to the conclusion that ALTER EXTENSION ..
UPGRADE is pretty much a must-have for a useful feature regardless of
this issue. I had previously thought that we might be able to limp
along with half a feature for one
On Feb 8, 2011, at 10:03 AM, Robert Haas wrote:
No, this is not doable, or at least not in a way that provides any
benefit over just dropping and reinstalling. The problem is that it
is going to fall down all over the place if other objects are
depending on objects provided by the extension.
On Feb 8, 2011, at 10:24 AM, Tom Lane wrote:
Ah, right, of course. I don't suppose CREATE OR REPLACE would work, either,
in some cases at least?
But figuring out just what commands to issue is pretty nearly AI-complete.
The whole point of ALTER EXTENSION UPGRADE is to have a human do that
On Feb 7, 2011, at 8:57 AM, Tom Lane wrote:
Yeah, this is another approach that one could take instead of having
per-row flags. I'm not sure that it's better, much less so much better
that we should force extensions to do it that way and not the other.
But it's definitely another argument
On Feb 7, 2011, at 9:20 AM, Dimitri Fontaine wrote:
Also, I didn't bite this bullet, but maybe we should provide core PLs as
extension. Then CREATE LANGUAGE would maybe get deprecated and only
valid when used in an extension's script — or the next patch (UPGRADE)
will take care of create a
On Feb 7, 2011, at 9:51 AM, Tom Lane wrote:
Interesting point. It's all right at the moment because I tweaked
pg_dump_sort.c so that procedural languages are dumped before modules.
But maybe we should convert the PLs to modules.
s/modules/extensions/?
David
--
Sent via pgsql-hackers
On Feb 7, 2011, at 10:23 AM, Tom Lane wrote:
On reflection, the set of extensions that an extension depends on is
obviously a property of the extension, which means it ought to be
specified in the extension's control file, not in the CREATE EXTENSION
command. So now I'm thinking something
On Feb 6, 2011, at 10:23 AM, Tom Lane wrote:
I've not attempted to implement this idea, but offhand it looks like
it would take a day or two's work, which seems well worthwhile to
expend now in the hope of getting this feature right the first tim
Seems worthwhile, and a much better approach.
On Feb 4, 2011, at 7:48 AM, Robert Haas wrote:
I'd like to answer this question, but I have not had enough time to
read through this patch in detail, because there are 97 patches in
this CommitFest. The point I'm trying to make, however, is
procedural. We shouldn't commit anything at the
On Feb 4, 2011, at 8:54 AM, Robert Haas wrote:
Yeah, I understand. I believe Tom said he was going to look at the
basic functionality with an eye toward commit, and I hope to look at
it as well, either before or after it gets committed. Time
permitting, I'd then like to look at this, but
On Feb 3, 2011, at 4:23 AM, Alexey Klyukin wrote:
- Making the conversion lazy would be a big help.
Converting it to string is already lazy, and, per the argumens above, I don't
see a real benefit of lazy conversion to the perl reference (as comparing to
the hurdles of implementing that).
On Feb 3, 2011, at 9:38 AM, Tom Lane wrote:
Given that pg_upgrade is now considered a supported piece of the system,
ISTM that most real-world upgrade scenarios will be accomplished with
pg_upgrade relying on provision (3). It looks to me like we're talking
about adding a large amount of
On Feb 3, 2011, at 9:54 AM, Robert Haas wrote:
I think you can pretty much take it to the bank that there will be
demand. This is an important, real-world problem.
That having been said, I'm not 100% convinced that the main extensions
patch is ready for prime-time, and I'm even less
On Feb 3, 2011, at 10:07 AM, Tom Lane wrote:
Well, pg_upgrade is designed to work within a major-version series, eg
you could do a 9.1-to-9.1 upgrade if you needed to install a newer
version of an extension. Admittedly, this is swinging a rather larger
hammer than apply an upgrade script
On Feb 3, 2011, at 11:02 AM, Tom Lane wrote:
That's putting it mildly. It's more like sending a rocket into outer
space to tweak the orbit of a comet so that it crashes into your
barbecue grill to light a fire so you can roast marshmallows.
LOL.
No, it's more like using a sledgehammer to
On Feb 3, 2011, at 11:35 AM, Josh Berkus wrote:
(D) Requires a series of ordered upgrade scripts in sortable version
numbering, each of which gets applied in order between the two versions.
This initially seems like the most attractive option -- and is the one
used by dozens of popular open
On Feb 2, 2011, at 6:45 AM, Dimitri Fontaine wrote:
Well, you write 3 scripts.
Let's consider an example, the lo contrib, with its 3 objects:
CREATE DOMAIN lo AS pg_catalog.oid;
CREATE OR REPLACE FUNCTION lo_oid(lo) …
CREATE OR REPLACE FUNCTION lo_manage() …
Now, the upgrade script
On Feb 2, 2011, at 9:03 AM, Dimitri Fontaine wrote:
Well, fair enough I suppose. Or it would be if you gave me an
alternative that provides a simpler way to support those 3 upgrades.
I did: a naming convention with upgrade scripts that have the version number in
them. You rejected it.
Of
On Feb 2, 2011, at 9:19 AM, Dimitri Fontaine wrote:
I see there no solution to your reaction here. Please take the time to
tell us more about what exactly it is that you hated, and how to make it
lovely. We won't make any progress with your current commenting style.
Here is your example of
On Feb 2, 2011, at 10:04 AM, Dimitri Fontaine wrote:
David E. Wheeler da...@kineticode.com writes:
They are identical except for the extra line in the second one. If I
had, say 15 different versions of an extension, then I'd have 15
upgrade scripts. That's fine. But in your plan, the script
On Feb 2, 2011, at 10:14 AM, Aidan Van Dyk wrote:
My concern with this approach (upgrade is forced through all
intermetiary versions) is that the shared libray now for version 15
*has* to have all the intermediary compatibility for *all* versions
in it. So it has to have functions with all
On Feb 2, 2011, at 10:22 AM, Dimitri Fontaine wrote:
Either one line in the Makefile or a new file with the \i equivalent
lines, that would maybe look like:
SELECT pg_execute_sql_file('upgrade.v14.sql');
SELECT pg_execute_sql_file('upgrade.v15.sql');
So well… I don't see how you've
On Jan 29, 2011, at 10:57 AM, Jeff Davis wrote:
On Fri, 2011-01-28 at 10:41 -0800, David E. Wheeler wrote:
+1 in principal. I think we should try to avoid the user of the term
period if possible, and I see definite benefits to a simple model of
$typename . 'range';
Interesting, I didn't
On Jan 28, 2011, at 9:48 AM, Jeff Davis wrote:
On Fri, 2011-01-28 at 09:17 -0800, David Fetter wrote:
For consistency, and in order not to continue our atrocious naming
tradition, I'd like to propose that the above be named timestamprange
(tsrange for short) and timestamptzrange (tstzrange
On Jan 27, 2011, at 9:17 AM, Tom Lane wrote:
The Postgres core team will be wrapping update releases for all
supported back branches this evening. These updates are prompted by
a minor security issue (reported by Apple, curiously enough) as well
as desire to push out some significant bug
On Jan 26, 2011, at 7:48 AM, Richard Broersma wrote:
On Wed, Jan 26, 2011 at 7:38 AM, David Fetter da...@fetter.org wrote:
I'm thinking that we should consider *very* carefully before we
introduce payments into what had been an all-volunteer effort. You
may get people to do things they
On Jan 26, 2011, at 9:40 AM, Richard Broersma wrote:
On Wed, Jan 26, 2011 at 9:31 AM, David E. Wheeler da...@kineticode.com
wrote:
Part of GCOC's success has been in allowing a class of people to
participate who otherwise would have had to get summer jobs flipping
burgers
On Jan 25, 2011, at 7:27 AM, David Fetter wrote:
Other than adminpack, I think it makes sense to say that extensions
are not going into pg_catalog…
Given this, we should maybe see about either making adminpack part of
PostgreSQL's core distribution (probably a good idea) or moving it out
On Jan 18, 2011, at 1:39 PM, Tom Lane wrote:
At the moment my opinion is that gist__int_ops is too broken to be
usable, and it's also too uncommented to be fixable by anyone other
than the original author.
That seems to jibe with your comments from last year:
On Jan 18, 2011, at 1:58 PM, Tom Lane wrote:
I'm noticing also that I get different rowcounts than you do, although
possibly that has something to do with the partial-index conditions,
which I'm not trying to duplicate here (all rows in my table pass those
two tests).
Shall I send you data
On Jan 18, 2011, at 3:08 PM, Tom Lane wrote:
Shall I send you data with the other two columns?:
No, I see no reason to think that has much to do with it. I'm wondering
if your table is itself a bit bloated ...
Nope. Just ran the bloat query from check_postgres.pl. Bloat is 0. Not
On Jan 18, 2011, at 3:46 PM, Tom Lane wrote:
The above is using the index, but only as a guide to where the rows
satisfying the partial-index predicate are --- note the lack of any
index condition in the indexscan node. That's because the query_int
query is not in fact compatible with the
On Jan 14, 2011, at 11:37 PM, David E. Wheeler wrote:
Hard to comment on any of this without a concrete example (including
data) to look at. Given the bugs we've recently found in the picksplit
algorithms for other contrib modules, I wouldn't be too surprised if the
sucky GiST performance
On Jan 15, 2011, at 6:50 AM, Robert Haas wrote:
It is really already too late for us to be seriously considering
integrating sync rep into 9.1. It will lead to another enormous beta
period during which the tree will be closed to new patches and
everyone will complain, or else we'll open the
On Jan 13, 2011, at 1:58 PM, Alvaro Herrera wrote:
Something else that might be of interest: the patch as presented here
does NOT solve the deadlock problem originally presented by Joel
Jacobson. It does solve the second, simpler example I presented in my
blog article referenced above,
On Jan 8, 2011, at 9:41 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
On Jan 7, 2011, at 4:19 PM, Tom Lane wrote:
Well, actually, I just committed it. If you want to test, feel free.
Note that right now only the anyarray @ @ operators are genuinely
fixed ... I plan
On Jan 14, 2011, at 5:54 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
So some questions:
* Is something seriously wrong with GiST index creation on integer[] columns?
* Why does GIN performance appear to be no better than table scans on
integer[] columns?
* Why
On Jan 13, 2011, at 4:15 PM, Stephen J. Butler wrote:
Suppose one of these compatibility objects is passed into legacy code
as $_[0]. The problem is that 'ref $_[0]' will return 'Pg::ArrayArg'
instead of what it used to, '' (empty string). Other than that, I
think it performs as people would
On Jan 12, 2011, at 5:14 AM, Alexey Klyukin wrote:
You mean packing both a string representation and a reference to a single SV
* value?
Dunno, I'm not a guts guy.
I haven't considered that (lack of extensive perlgus-foo) although I think
that's an interesting idea. One drawback would be
On Jan 12, 2011, at 8:48 AM, Robert Haas wrote:
I guess that begs the question of why we need to allow users to call
type output functions directly.
I've used them quite a lot in the past; less so on 8.4+ where casting
everything to text became a lot easier.
Best,
David
--
Sent via
On Jan 12, 2011, at 11:22 AM, Alex Hunsaker wrote:
Personally, I think the point of a compatibility GUC is that at some
point in the distant future we can get rid of it. If we default to
the old behavior thats going to be harder to do. +1 for defaulting to
the new behavior.
+1
[ Id
On Jan 12, 2011, at 11:36 AM, Alvaro Herrera wrote:
[ Id actually vote for _not_ having a compatibility option at all, we
change more major things than this IMHO every major release. (And even
then some major things in minor releases, for example the removal of
Safe.pm) ]
I think the main
On Jan 12, 2011, at 11:51 AM, Alvaro Herrera wrote:
I suspect it'd be quiet, unfortunately, since there are a bazillion ad hoc
implementations of a Perl SQL array parser, and many of them, I suspect,
don't complain if the string doesn't look like an SQL array. They would just
parse a
On Jan 12, 2011, at 3:29 PM, Robert Haas wrote:
What I was casting a bit of doubt on upthread was whether or not this would
work without possibly breaking some code, in possibly silent or obscure
ways. If I'm wrong about that, then by all means let's use some perl Magic
(that's a technical
Tom,
On Jan 8, 2011, at 9:41 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
On Jan 7, 2011, at 4:19 PM, Tom Lane wrote:
Well, actually, I just committed it. If you want to test, feel free.
Note that right now only the anyarray @ @ operators are genuinely
fixed ... I
On Jan 12, 2011, at 4:35 PM, Tom Lane wrote:
Did a signature change or something?
Yeah. I think if you just load up the current contrib/intarray first,
you'll be fine (ignore all the object-already-exists errors).
Oh, from 9.1devel? yeah, okay. Will do that tomorrow (finishing the current
On Jan 11, 2011, at 2:25 PM, Alexey Klyukin wrote:
Hello,
Here's the patch that improves handling of arrays as pl/perl function input
arguments, converting postgres arrays of arbitrary dimensions into perl array
references.
Awesome! I've wanted this for *years*.
It includes regression
On Jan 11, 2011, at 3:44 PM, Andrew Dunstan wrote:
I think there's at least a danger of breaking legacy code doing that. Say you
have some code that does a ref test on the argument, for example. The
behavior would now be changed.
I think that'd be pretty rare.
David
--
Sent via
501 - 600 of 1565 matches
Mail list logo
