On Jul 28, 2010, at 7:57 AM, Joshua D. Drake wrote:
Hah! I gave you kudos :P (you are in the FAQ)
Ah, thanks. The link is missing a G: It's PGXN, not PXN.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Jul 27, 2010, at 3:01 PM, Joshua D. Drake wrote:
Correct. We are also hoping to get some sponsorship for it.
https://www.fossexperts.com/
Frigging copycat.
Any sponsorship for PGXN in there? ;-P
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Jul 18, 2010, at 1:35 AM, Peter Eisentraut wrote:
I think there are two ways we can do this, seeing that most appear to be
in favor of doing it in the first place: Either we just flip the
default, make a note in the release notes, and see what happens. Or we
spend some time now and make,
On Jul 16, 2010, at 6:17 AM, Thom Brown wrote:
Joy! :) Nice patch Robert.
Indeed.
What are the implications for pg_upgrade? Will a database with values created
before the patch continue to work after the patch has been applied (as happened
with the new hstore in 9.0), or will pg_upgrade
On Jul 16, 2010, at 9:04 AM, Bruce Momjian wrote:
What are the implications for pg_upgrade? Will a database with values
created before the patch continue to work after the patch has been
applied (as happened with the new hstore in 9.0), or will pg_upgrade
need to be taught how to upgrade the
On Jul 16, 2010, at 9:09 AM, David Fetter wrote:
Clarification, do enough people use non-psql command line tools to
warrant putting this in the backend?
Yes. Such backend stuff is in every RDBMS except ours.
I admit that I had to do a *lot* of work to write the schema-testing functions
On Jul 8, 2010, at 9:20 PM, Robert Haas wrote:
/me opens a beer.
How long should I wait before I start breaking things?
I should think that you would need to drink at least 5-6 beers before you
started stumbling around and breaking shit.
David
--
Sent via pgsql-hackers mailing list
On Jun 28, 2010, at 12:10 PM, Tom Lane wrote:
While I would personally prefer to have an operator for the slicing
opeeration, I'm not willing to spend time arguing about it. So, +1 to
implement the subset operation as the function slice(), and defer having
an operator until later.
Yeah, I
On Jul 2, 2010, at 10:07 AM, Robert Haas wrote:
Yeah, I think the consensus is to avoid picking an operator name at all.
slice() is OK by me.
Will this be done for Beta 3?
You forgot to attach the patch. :-)
Attached.
Only thing that gave me pause is the presence of the undocumented
On Jul 2, 2010, at 1:38 PM, Robert Haas wrote:
Thanks, committed - with the exception that I reverted your change to
the title of section F.13.2, which I believe was in error (and
possibly accidental).
No, I removed that because that table has only operators, no functions. See
On Jul 2, 2010, at 1:45 PM, Robert Haas wrote:
No, I removed that because that table has only operators, no functions.
Seehttp://developer.postgresql.org/docs/postgres/hstore.html.
The section contains two tables. Table F-5 is called hstore
operators, and table F-6 is called hstore
On Jun 29, 2010, at 7:44 AM, Thom Brown wrote:
No. Or are you volunteering?
A n00b like me volunteer for that? It's more of a suggestion.
N00bs gotta start somewhere…
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Jun 16, 2010, at 3:37 AM, Dave Page wrote:
heh I'm with Robert on that PGXN just sounds and speels weird - PGAN was
much easier ;)
+1
Seriously? To me, “pee-gan” just didn't sound nice. And the acronym,
“PostgreSQL Add-on Network,” wasn't as good, since it's mainly
extension-focused. I
On Jun 21, 2010, at 9:20 AM, Robert Haas wrote:
Per that email, and subsequent concurrence, here is a series of
patches which does the following:
1. In CVS HEAD, document the hstore(text, text) function and adjust
CREATE OPERATOR to throw a warning when = is used as an operator
name, using
On Jun 17, 2010, at 1:30 PM, Florian Pflug wrote:
How about turning it into a function
hstore hstore(hstore, text[])
instead?
I just searched through the 2008 spec for a slice/subset operator and came up
empty. It seems to define a bunch of predicates for multisets, but not much for
On Jun 21, 2010, at 10:46 AM, Robert Haas wrote:
I don't much like hstore(hstore, text[]) because it's not strictly a
constructor. But I could certainly live with something based on the
word slice. The existing SQL function backing the operator is called
slice_hstore(), whereas I would
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
adjacent
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 it's
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
--
Sent via
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? And,
On Jun 16, 2010, at 4:58 PM, Tom Lane wrote:
hstore = text[] is new in 9.0.
Wup, sorry, I read this as being the other operator. Nevermind ...
(FWIW, I share your dislike of for this operator. I just haven't
got a better idea.)
There aren't any very good choices. Possible correlates:
On Jun 17, 2010, at 1:50 PM, Josh Berkus wrote:
It isn't. || already does what you're saying.
So what *does* it do?
It returns an hstore that's effectively a slice of another hstore. From the
docs (http://developer.postgresql.org/pgdocs/postgres/hstore.html):
'a=1,b=2,c=3'::hstore =
On Jun 17, 2010, at 4:15 PM, Tom Lane wrote:
Using % would also mean that sometime in the future we can implement !%
as elements NOT in this list (i.e. ' a = 1, b = 2, c = 5' !% 'a, b'
== 'c = 5' )
You can prepend ! to any operator name at all, so that's not much of
a differentiator.
%!
On Jun 16, 2010, at 4:24 PM, Robert Haas wrote:
Put me down for +.
Since there are no other votes for that option (or, indeed, any other
option), I'm going to go with my original instinct and change hstore
= text[] to hstore text[]. Patch to do that is attached.
Damn. My other argument
On Jun 16, 2010, at 4:53 PM, Tom Lane wrote:
Um ... wait a minute. What happened to backwards compatibility?
I thought the idea was to deprecate = for a release or so, not kill it
on the spot.
hstore = text[] is new in 9.0.
David
--
Sent via pgsql-hackers mailing list
On Jun 15, 2010, at 1:12 PM, Bruce Momjian wrote:
This was just posted to announce. Seems the community now has to
compete with another extension-based infrastructure if we ever get
around to developing one of our own.
I personally had no knowledge of this, which is fine, but don't expect
On Jun 15, 2010, at 2:06 PM, Ross J. Reedstrom wrote:
One issue that will come up: this is clearly a more commercial
enterprise than Jarkko's CPAN (and the internet is a different place
than it was in 1995) You pushed money right to the front with this, so
that will lead to certain questions
On Jun 15, 2010, at 3:23 PM, Robert Haas wrote:
I think this project is a great idea, and I think as a community we
ought to be behind it 100%.
However, I do wonder what happened to the original name, which IIRC
was PGAN. That seems easier to pronounce, remember, ...
I didn't care for it,
On Jun 15, 2010, at 3:22 PM, Bruce Momjian wrote:
I totaly agreed you need funding, and you are very well qualified to do
this, and it is a badly needed facility.
Thanks.
The problem I had is that the effort appeared to be I am creating my
own sandbox, fund me (particularly the FAQ), which
On Jun 15, 2010, at 3:13 PM, Robert Haas wrote:
On Mon, Jun 14, 2010 at 4:35 PM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
I'm happy with deprecating the first two = in favour of hstore() if
that is in line with general opinion. The hstore = text[] slice could
be replaced by another
On Jun 15, 2010, at 6:58 PM, Robert Haas wrote:
Well, the idea is it's like logical-and - give me only those keys that
appear on both sides...
Yeah, but = doesn't return the keys, - does. = returns an hstore.
If there is a critical mass of votes for one of these options, I'm
fine with
On Jun 11, 2010, at 2:23 PM, Tom Lane wrote:
hstore(key := 'this', key2 := 'that')
hstore(key = 'this', key2 = 'that')
hstore(row('this' AS key, 'that' AS key2))
The last of those is probably the easiest to get to. We already have
hstore_from_record:
Is not the first one simply a
On Jun 12, 2010, at 7:15 AM, Florian Pflug wrote:
It's reasonable to say that the first two are bad design, but I'm
a bit less willing to say that the last one is. What shall we
do with that?
Hm, the last one seems to be more akin to
hstore - textyields hstore (key removed)
On Jun 12, 2010, at 10:21 AM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
Which, IIRC, is new in 9.1, so could in theory be removed, especially if
there was an
hstore(text[], text[])
Oh --- now that I look, both that and the hstore = text[] one are new
in 9.0
On Jun 11, 2010, at 7:59 AM, Tom Lane wrote:
How about no operator at all? It won't be as cool to read, but
consider, the arguments are text and text, not involving any hstore type
at all, so whatever operator you choose is in practice blocked from
everyone everywhere. No one could ever
On Jun 11, 2010, at 9:58 AM, Tom Lane wrote:
That would make it so that the use of = in hstore strings would be less
consistent. Makes sense to me.
Less inconsistent, ITYM? But yeah, then we would have no reason to
fiddle with hstore_in, which is good.
Yes, sorry.
David
--
Sent via
On Jun 9, 2010, at 9:30 AM, Tom Lane wrote:
Andrew Gierth and...@tao11.riddles.org.uk writes:
I'd really like to find a better operator name than ==. But I'm not
convinced one exists.
I agree.
+1
No one liked my suggestion of ~ ? Too similar to - ? Other ideas:
'foo' : 'bar'
'foo' @
On Jun 9, 2010, at 10:04 AM, Tom Lane wrote:
I actually like : pretty well. It looks more like =, and has nice
correspondence to := for named function params.
Colon was removed from the set of allowed operator-name characters years
ago. There are conflicts with various usages (ecpg psql
On Jun 9, 2010, at 10:33 AM, Robert Haas wrote:
Well, that doesn't look much like an arrow, at least not to me...
It's a pointer, though. Not in the C sense, of course. But I often use » for
read more style links in HTML. Its the same idea: move from this to that.
Anyway, for comparison's
On Jun 8, 2010, at 12:34 PM, Merlin Moncure wrote:
hm. any chance of a shorter operator, like '#'? I kinda agree that
hstore_in and the operator don't have to be the same, but requiring
three letter token for the two most high traffic operations w/hstore
seems off to me.
# is currently
On Jun 5, 2010, at 7:02 AM, Tom Lane wrote:
From a usability point of view, if we adopt the spec's syntax we have to
stop allowing = for any other purpose. Period.
What if we added a new dual type and limited the = operator only to that
type, being, essentially, a constructor. Then hstore
On Jun 3, 2010, at 8:54 AM, Tom Lane wrote:
Thinking some more, what is the value of keeping = in hstore for 9.0?
Backwards compatibility. You have not made any argument today that we
have not been over many times before. I do not have time to argue
about this today --- I have to go fix
On Jun 3, 2010, at 8:53 AM, Dimitri Fontaine wrote:
Now that it's pretty clear from Peter that the standard is not going to
change its choice here, I'll vote adding a WARNING each time an operator
called = is created, so that we get a chance to move later on.
Should support for == be added to
On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote:
I don't have strong feelings about the timing - I'd be very surprised if :=
were to be used in this context for any other purpose, so I don't think we'd
be biting ourselves too much by just using that now. But if we do that, we
should
On May 31, 2010, at 7:40 PM, Robert Haas wrote:
I was going to propose == across the board.
What about - ?
D
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On May 27, 2010, at 9:59 AM, Tom Lane wrote:
I think we should fix it now. Quick thought: maybe we could use FOR
instead of AS: select myfunc(7 for a, 6 for b);
I'm afraid FOR doesn't work either; it'll create a conflict with the
spec-defined SUBSTRING(x FOR y) syntax.
How about
On May 27, 2010, at 11:55 AM, Robert Haas wrote:
Or we could use the Finnish word
epäjärjestelmällistyttämättömyydellänsäkäänköhän, which I'm pretty
sure is not currently used in our grammar.
I thought that was an Icelandic volcano.
Best,
David
--
Sent via pgsql-hackers mailing list
On May 26, 2010, at 4:09 PM, alvherre wrote:
The problem with the = operator seems best resolved as not accepting
such an operator in a function parameter, which sucks but we don't seem
to have a choice. Perhaps we could allow = to resolve as the
operator for the case the user really needs
Just picking up a dropped thread, does anyone have a patch for this?
http://archives.postgresql.org/pgsql-hackers/2010-04/msg01191.php
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On May 17, 2010, at 11:20 AM, Peter Eisentraut wrote:
We have in 9.0 plperl.c
errcontext(while executing PostgreSQL::InServer::SPI::bootstrap)));
errcontext(while parsing Perl initialization)));
errcontext(while running Perl initialization)));
errcontext(While executing PLC_TRUSTED.)));
On May 12, 2010, at 4:07 PM, Bruce Momjian wrote:
I like 'pg_upgrade_support'. I could also do 'pg_upgrade_funcs'.
I misread the second one at a glance, so I recommend the first.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Apr 6, 2010, at 1:59 AM, Andrew Dunstan wrote:
This needs to be profiled. Otherwise we'd just be speculating on possible
causes with no real hard data. (This is where tools like oprofile come in
handy, but I have no idea if something similar is available on OSX.)
I think OS X has
On Apr 6, 2010, at 2:32 AM, Takahiro Itagaki wrote:
In our test, which does 5801 of these pings during the test, they take
an average of 15x longer to execute on 9.0 as 8.4 ( 0.77ms vs. 0.05ms ).
Any clue why this would be?
Did you use the same configure options between them?
Yes.
For
On Apr 6, 2010, at 6:07 AM, Merlin Moncure wrote:
In our test, which does 5801 of these pings during the test, they take
an average of 15x longer to execute on 9.0 as 8.4 ( 0.77ms vs. 0.05ms ).
did your pings change?
No.
David
--
Sent via pgsql-hackers mailing list
On Apr 6, 2010, at 7:28 AM, Tom Lane wrote:
There's something wrong with your test setup. Or, if you'd like me to
think that there isn't, provide a self-contained test case. I ran a
small program that does
for (i = 0; i 1; i++)
{
res = PQexec(conn, SELECT
On Apr 6, 2010, at 9:08 AM, David E. Wheeler wrote:
For example, --enable-debug or --enable-cassert.
No.
Oh FFS! I was looking at the wrong build script. It was indeed built with
--enable-cassert --enable-debug. Grrr.
Well, that's likely the culprit right there. I'm rebuilding without
On Apr 6, 2010, at 10:17 AM, Tom Lane wrote:
So I'm not sure where your 15x is coming from, but I don't see it.
By stupidly having configured with --enable-cassert --enable-debug without
realizing it. I've just rebuilt without them and run the tests again using the
default postgresql.conf and
On Apr 6, 2010, at 10:52 AM, David E. Wheeler wrote:
Oh FFS! I was looking at the wrong build script. It was indeed built with
--enable-cassert --enable-debug. Grrr.
Well, that's likely the culprit right there. I'm rebuilding without those now
and hopefully my tests will be back down
On Apr 6, 2010, at 11:15 AM, Tom Lane wrote:
By stupidly having configured with --enable-cassert --enable-debug without
realizing it. I've just rebuilt without them and run the tests again using
the default postgresql.conf and I'm back down to 57s and 46s over two runs.
Huh. I'm still
On Apr 6, 2010, at 12:50 PM, Tom Lane wrote:
I hadn't, but since you mention it: 10 iterations take about 7.5sec
with non-assert CVS HEAD and 15sec with asserts, on a 2008 Macbook Pro.
Color me still confused.
Well it's not just pings that the bricolage tests were running, of course.
Hackers,
I tried this:
try=# create or replace function try() returns void language plperl as $$
spi_prepare('select length($1)', 'unknown');
$$;
CREATE FUNCTION
try=# select try();
ERROR: error from Perl function try: failed to find conversion function
from
On Apr 6, 2010, at 4:40 PM, Tom Lane wrote:
I tried this:
try=# create or replace function try() returns void language plperl as $$
spi_prepare('select length($1)', 'unknown');
$$;
CREATE FUNCTION
try=# select try();
ERROR: error from Perl function try: failed to
On Apr 6, 2010, at 4:55 PM, Andrew Dunstan wrote:
Indeed it doesn't. But (as documented) the argument will be passed *from*
*perl* as text and converted to the specified type in the glue code. See
plperl.c for details.
Hrm. If the type is unknown, I think it should just be passed as a
On Apr 6, 2010, at 4:54 PM, Tom Lane wrote:
try=# create or replace function try() returns void language plperl as $$
spi_prepare('select abs($1)', 'text');
$$;
CREATE FUNCTION
try=# select try();
ERROR: error from Perl function try: function abs(text) does not exist
On Apr 6, 2010, at 5:06 PM, Tom Lane wrote:
Somehow, emulating the above doesn't attract me nearly as much as it
evidently does you. What happens in cases where the parser is unable
to infer a data type, or infers the wrong one?
An exception should be thrown.
Or even if it does
infer a
On Apr 6, 2010, at 5:23 PM, Andrew Dunstan wrote:
It has been suggested in the past that we should have a full DBD interface in
plperl, and indeed there was such an animal at one stage, although it was not
compatibly licensed, and it is probably now way out of date.
The current plperl
Hackers,
Followup to Josh's posts.
I'm getting Bricolage 2.0 ready to ship, and took some time to test it on
PostgreSQL 9.0 today. I built PostgreSQL from Git/master with:
./configure --with-libs=/usr/local/lib
--with-includes=/usr/local/include --prefix=$BASE --with-perl PERL=$PERL
On Apr 1, 2010, at 9:34 PM, Petr Jelinek wrote:
I ended up reinventing the wheel and writing another JSON library:
http://constellationmedia.com/~funsite/static/json-0.0.1.tar.bz2
This is a first release, and it doesn't really have a name besides
json. It's very similar to cJSON, except
On Apr 1, 2010, at 3:01 AM, Magnus Hagander wrote:
I prefer to dump all my data in a big text file and grep it for the
information I need.
As long as you implement your own grep, that sounds about on par with
the current trends! Go for it!
Well, first you have to implement your own
On Mar 31, 2010, at 5:42 PM, Matthew Altus wrote:
After dealing with a production fault and having to rollback all the time, I
kept typing a different word instead of rollback. So I created a patch to
accept this word as an alias for rollback. Obviously it's not part of the
sql
On Mar 29, 2010, at 9:02 AM, Tom Lane wrote:
If this is going to end up being one fairly small C file implementing
a spec that is not a moving target, I'd vote against depending on an
external library instead, no matter how spiffy and license-compatible
the external library might be.
Perhaps
On Mar 14, 2010, at 3:38 PM, Josh Berkus wrote:
I'm planning on writing a Guide to HS SR for the beta. Originally I
planned to put this in the main docs, but I couldn't figure out how to
fit it in there structurally. Plus, it needs more examples, output
samples, and a tutorial feel.
On Mar 9, 2010, at 6:30 AM, Pavel Stehule wrote:
this patch contains a string formatting function format
postgres=# select format('some message: % (current user: %)',
current_date, current_user);
format
some message:
On Mar 8, 2010, at 8:03 AM, Tom Lane wrote:
#3 is still an absolute nonstarter, especially for a patch that we'd
wish to backpatch.
You're at least going to want to exclude Safe 2.20 - 2.23, IIUC.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Mar 8, 2010, at 9:14 AM, Tom Lane wrote:
If those aren't versions that are likely to be in wide use, no objection
to that.
Yes, those are a series of releases in the last couple of months that had one
level of brokenness or another I'm going to test 2.25 today.
I'm just concerned about
On Mar 2, 2010, at 4:33 PM, Andrew Dunstan wrote:
I propose to add the following note to the docs:
Preloading modules using plperl.on_init does not make them available
for use by plperl. External perl modules can only be used in plperlu.
Perhaps add a note that some other interface to
On Mar 2, 2010, at 5:14 PM, Tom Lane wrote:
Rather than trying to fix this, I think we should just rip it out and
allow only the documented syntax. Objections?
+1 If it never worked, seems like a no-brainer.
Best,
David
PS: Do you have builds of 7.0 laying around? Sheesh!
--
Sent via
On Mar 2, 2010, at 6:00 PM, Andrew Dunstan wrote:
Perhaps add a note that some other interface to allow preloaded modules to
also be available to plperl may be provided in the future.
No, that's far from a done deal.
Hence the “may.” But either way.
David
--
Sent via pgsql-hackers
On Feb 24, 2010, at 12:47 PM, Tom Lane wrote:
OK, so we need a way out of that cycle if the user is issuing
pg_stop_backup because they *already know* that archive_command is
failing. Right now, there's no way out other than a fast shutdown,
which is a bit user-hostile.
The
On Feb 24, 2010, at 3:24 PM, Tom Lane wrote:
If you like the concept, then the next question is exactly how to phrase
the messages. All we have at the moment is the inside-the-delay-loop
warning:
ereport(WARNING,
(errmsg(pg_stop_backup still waiting for archive to complete
On Feb 20, 2010, at 9:49 AM, Tom Lane wrote:
This discussion is sounding very design-ish, which makes me think we
should just leave things unchanged for 9.0 and have external regression
test designers work around this problem in their Makefiles, as Alvaro
suggested.
I would have said that
On Feb 20, 2010, at 11:03 AM, Bruce Momjian wrote:
There is also the must fix issue with pg_regress.
Why? My pg_regress runs just fine. If you are talking about 3rd party
modules, I suggested conditional Makefile rules.
Because you can either make the simple change to pg_regress that
On Feb 20, 2010, at 15:03, Tom Lane t...@sss.pgh.pa.us wrote:
Well, I'm willing to implement CREATE OR REPLACE LANGUAGE if people
are agreed that that's a reasonable fix. I'm slightly worried about
the restore-could-change-ownership issue, but I think that's much less
likely to cause problems
On Feb 20, 2010, at 15:18, Andrew Dunstan and...@dunslane.net wrote:
I also think we need to state explicitly that module authors can not
expect build files to be version ignorant and always work. Even if
we do something that handles this particular issue, that is likely
to be a happy
On Feb 20, 2010, at 3:57 PM, Tom Lane wrote:
And if so, would that be a syntax we'd want to accept in general?
Could the be a CREATE IF NOT EXISTS TABLE?
*Please* go read some of the linked older discussions before you propose
that. I don't want to rehash it yet again.
:-) Was just a
On Feb 19, 2010, at 5:36 AM, Alvaro Herrera wrote:
Because it's a lot easier for `pg_regress --load-language=plpgsql` to mean
ensure the language is installed than it is for 3rd-party test suites to
detect what version they're being installed against.
Why doesn't the Makefile running the
On Feb 19, 2010, at 7:43 AM, David E. Wheeler wrote:
Usually PGXS loads after setting all the environment variables, though I
suspect that it wouldn't have any side effects to set regress_opts afterward.
Also, there is no MAJORVERSION in earlier versions, so module authors would
have
On Feb 18, 2010, at 1:35 AM, Tim Bunce wrote:
http://github.com/timbunce/posgtresql-plperl-call
Thanks, forked.
Thanks. I quite like FN.
Anybody else want to express an opinion on the color if this bikeshed
before I repaint it?
I like PG because it lets you know that you're calling a
On Feb 18, 2010, at 1:01 PM, Greg Sabino Mullane wrote:
Is the payload decoded to utf8 when pg_enable_utf8 is true?
No - there's a note in the code to look into that at some point. So
stick to ASCII for the moment. I'm sure the great DBD::Pg utf-8
overhaul (where we get rid of the
On Feb 18, 2010, at 3:27 PM, Tom Lane wrote:
While hacking on PL/Parrot, I ran across an issue where when trying to
load PL/pgsql, it's done unconditionally and fails. How do we fix
pg_regress to be a little more subtle about this?
Why exactly would we want it to not fail? Regression
On Feb 18, 2010, at 8:38 PM, Tom Lane wrote:
The regression test in the core is targeting only its version,
but some external projects have version-independent tests.
I think it's more like are under the fond illusion that their tests are
version-independent. Are we going to back out the
On Feb 17, 2010, at 4:28 AM, Tim Bunce wrote:
Yes, but if it's a variadic function, I suspect that it won't often be
called with the same number of args. So you'd potentially end up
caching a lot of extra stuff that would never be used again.
Potentially. Patches welcome!
GitHub. ;-P
On Feb 17, 2010, at 10:04 AM, Greg Sabino Mullane wrote:
while (my $notify = $dbh-pg_notifies) {
my ($name, $pid, $payload) = @$notify;
print qq{I received notice $name from PID $pid, payload was $payload\n};
}
Not sure what you mean by adapting interfaces to send
On Feb 16, 2010, at 4:08 AM, Tim Bunce wrote:
Yes, IIRC, 0 == unknown as far as the server is concerned. It just
tells the server to resolve it when it can.
An extra source of puzzlement is that the oid of the 'unknown' type is
705 not 0, and the unknown type isn't discussed in the docs (as
On Feb 16, 2010, at 9:43 AM, Richard Huxton wrote:
Perhaps it would be better to be explicit about what's going on?
SEARCHPATH-function()
SCHEMA('public')-function2()
Or did SP mean Stored Procedure?
Yes.
On a (kind of) related note, it might be worthwhile to mention search_path in
On Feb 16, 2010, at 2:06 PM, Tim Bunce wrote:
I assume that type names can be omitted her, too, yes?
No, it seems not. You have to either repeat the type name the right number
of times, or use '...', which simply duplicates the type name for you
behind the scenes. I'll clarify that in the
On Feb 16, 2010, at 2:19 PM, Tim Bunce wrote:
It's certainly been an interesting introduction to PostgreSQL development!
Interesting, eh? Look forward to your blog post about the experience. ;-P
Tim.
p.s. One quick heads-up: David Wheeler has reported a possible issue
with Safe 2.21. I
On Feb 16, 2010, at 3:01 PM, Tom Lane wrote:
I think the reason the client-side docs recommend using zero is to avoid
having clients know about the unknown type explicitly (in particular, to
discourage people from hardwiring 705 into their code). AFAIR there's
not a lot of difference in
On Feb 15, 2010, at 2:51 AM, Tim Bunce wrote:
The signature doesn't just qualify the selection of the function,
it also ensures appropriate interpretation of the arguments.
I could allow call('foo', @args), which could be written call(foo = @args),
but what should that mean in terms of the
On Feb 15, 2010, at 2:42 PM, Tim Bunce wrote:
I've not really looked the the DBD::Pg code much so this seemed like a
good excuse... It looks like the default is to call PQprepare() with
paramTypes Oid values of 0.
Yes, IIRC, 0 == unknown as far as the server is concerned. It just tells the
801 - 900 of 1565 matches
Mail list logo
