On Sep 14, 2009, at 3:22 PM, Robert Haas wrote:
I might be able to make it. I expect to have the hstore patch to
review (I
reviewed it last fest).
It has not been resubmitted for this CommitFest.
He told me a few hours ago that he was working to get it done. Looks
like there's about 90
On Sep 14, 2009, at 4:32 PM, Robert Haas wrote:
What's wrong with just using a variant of the type input function?
With
a parameterized insert, it doesn't seem like it's really placing
much of
a burden on the application.
Agreed, I was thinking the same thing.
And the type output
On Sep 11, 2009, at 12:42 PM, Tom Lane wrote:
Well, 10.6.1 is out and it's still got the readdir() bug :-(.
Has someone filed a bug report about this with Apple?
https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa
Best,
David
--
Sent via pgsql-hackers mailing list
On Sep 9, 2009, at 6:13 PM, Robert Haas wrote:
Hopefully this plan is acceptable to everyone. If not, please feel
free to reply here.
+1
And I'm available to review again, of course.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Sep 10, 2009, at 10:16 AM, Tom Lane wrote:
Is that what's being proposed?
I think that's what currently works, given the limitations of arrays
(variadic arguments) to a single data type.
That pretty much sucks --- it's just
another way of concatenating some strings. I thought the
On Sep 10, 2009, at 11:16 AM, Tom Lane wrote:
no - we have to_char function, why we need different formatting
system?
Why do we need this at all, when we have the concatenation operator?
I think the point of it is that people are used to how sprintf works.
So it should work as nearly like
On Sep 10, 2009, at 12:10 PM, Tom Lane wrote:
SELECT sprintf('some %d', 10::mycustomtype)
For the formats that presume an integer or float input in C, perhaps
we could coerce to numeric (failing if that fails) and then print
appropriately. Or maybe int or float8 would be more appropriate
On Sep 10, 2009, at 2:08 PM, Hannu Krosing wrote:
Perhaps you should try changing ANY to a non-reserved word in the
parser and see what happens. If you come up with a way to resolve
the
shift/reduce and/or reduce/reduce conflicts that will probably
result,
submit a patch.
I don't want
On Sep 9, 2009, at 6:39 AM, Tom Lane wrote:
1. Is a completely unconstrained argument type (ie any) of any real
use to PL functions, and if so how can we expose that usefulness?
The only clear thing to do with such an argument is IS NULL/IS NOT
NULL
tests, which might or might not be worth
On Sep 9, 2009, at 10:04 AM, Tom Lane wrote:
Well, yeah: it looks like a fertile source of security holes, not to
mention implementation difficulties (plpgsql really wants well-typed
expressions...). What you can do at the C level is not necessarily
sane to give to PL authors. I'm willing to
On Sep 9, 2009, at 10:15 AM, Tom Lane wrote:
In order for this to work in general, we'd need FUNC_MAX_ARGS
different
types, which is currently defined as 100 in our code.
But here, any would work perfectly fine, since there's no need for
any two arguments to be tied to each other or the
On Sep 9, 2009, at 10:17 AM, Tom Lane wrote:
Well, none, *if* it's defined to have exactly the same runtime
behavior
as anyelement does. It sounded like you were arguing for something
looser. We could certainly define it as being just like anyelement
but not constrained to match any other
On Sep 9, 2009, at 10:22 AM, Tom Lane wrote:
Well, only if you write your functions in C. I'd like to be able to
write sprintf() in PL/pgSQL. Or PL/Perl, for that matter.
I think you're confusing the point with a secondary issue, which is
what
access we provide to these pseudotypes in PLs.
On Sep 8, 2009, at 9:12 AM, Alvaro Herrera wrote:
foo(anyelement, anyelement) returns anyelement
but this will force them to be both of the same type, which is not
what
we want. In my opinion this is a missing feature of our type system.
Oh yes, agreed. I've run into this with pgTAP many
On Sep 8, 2009, at 9:23 AM, Alvaro Herrera wrote:
2. does anybody have an idea how to attack it?
Why can't anyelement be freed from this constraint?
Because it would break other uses of it, I think. IIRC the original
use
of anyelement was that it would resolve to the element type of an
On Sep 8, 2009, at 9:25 AM, Tom Lane wrote:
If you don't want any constraints at all on the argument types, you
can use any (with the quotes, because it's a reserved word :-().
If you want some constraints but not anyelement, please be more
specific about what you want.
Oooh, I need to try
On Sep 8, 2009, at 9:57 AM, Tom Lane wrote:
Intentionally so, because there's not a whole lot you can *do* with an
ANY parameter, other than checking it for null. Perhaps the real
question is about what semantics you're expecting for these
unconstrained parameters.
For my purposes, I guess
On Sep 8, 2009, at 10:15 AM, Tom Lane wrote:
arg_a IS DISTINCT FROM arg_b
Surely you'd want arg_a and arg_b constrained to the same type,
otherwise there is no certainty that that means anything at all.
Yes, for the purposes of pgTAP perhaps so. Then it's on the user to do
the cast,
On Sep 8, 2009, at 9:32 AM, Alvaro Herrera wrote:
That would work, except that plpgsql and SQL don't like it:
ERROR: PL/pgSQL functions cannot accept type any
ERROR: SQL functions cannot have arguments of type any
Seems to go for other PLs, as well:
ERROR: PL/Perl functions cannot accept
On Sep 7, 2009, at 3:12 PM, Robert Creager wrote:
Building from CVS, but on closer examination I do have Macports
versions of bison/flex ahead of Apple's in the path.
Does your make config work? Are you using the 32 or 64 bit kernel?
Also, anyone tried compiling with LLVM and Clang?
On Sep 6, 2009, at 8:17 PM, Tom Lane wrote:
In principle this might enable use of Bonjour on non-Apple OSes, but
I'm not personally interested enough to test that ...
Comments, objections?
+1 Seems like a no-brainer.
Best,
David
--
Sent via pgsql-hackers mailing list
On Sep 2, 2009, at 5:07 AM, Merlin Moncure wrote:
One reason I don't like this proposal is that postgresql does not
preserve the original 'create view' statement for editing. The
resulting sql that is given to you to edit is hopelessly mangled and I
think it's not good to encourage people to
On Sep 2, 2009, at 4:42 PM, Josh Berkus wrote:
CF3 11/15 to 12/14
Alpha3 by 11/20
12/20?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sep 1, 2009, at 6:43 PM, Tom Lane wrote:
Debatable, but it's not upstream default, so why should it be
downstream
default?
FWIW, that particular issue is invariably a matter of distro policy;
they could care less what upstream's default is.
Well, they could, but do they?
/me offers
On Aug 28, 2009, at 3:45 PM, Stephen Frost wrote:
+1 from me. I've read the other comments and just plain don't agree
with them. It's a small patch, adds a useful format for EXPLAIN, and
would be used.
One of the best things about PG is the flexibility and usability.
I agree, I tend to
On Aug 19, 2009, at 11:48 AM, Tom Lane wrote:
(Personally, I use scripts based on start-scripts/osx/ for a number of
services on my own machines, so if there's something wrong with them
I'd definitely like to know what it is.)
+1. Please don't remove the start scripts. I use them on every
On Aug 19, 2009, at 2:03 PM, Tom Lane wrote:
These considerations don't apply to ordinary hand launching of the
postmaster, for the primary reason that the chance of a false PID
match
is several orders of magnitude smaller when you're talking about a
manual restart --- the likely postmaster
On Aug 11, 2009, at 5:32 AM, Bruce Momjian wrote:
OK, so it is warm slave.
I suggest steaming servant. Or tepid assistant.
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Aug 6, 2009, at 7:28 AM, Tom Lane wrote:
That would cover the problem for OIDs needed during CREATE TABLE, but
what about types and enum values?
I haven't been following this discussion very closely, but wanted to
ask: is someone writing regression tests for these cases that
On Aug 6, 2009, at 6:00 PM, Bruce Momjian wrote:
Yes, I have regression tests I run but they are not in CVS, partly
because they are tied to other scripts I have to manage server
settings.
Here are my scripts:
http://momjian.us/tmp/pg_migrator_test.tgz
One big problem is that
On Aug 4, 2009, at 11:10 PM, Tom Lane wrote:
Want me to change those or are you on it already?
I'm going to bed --- if you wanna do it, have at it ...
Oh please. Everyone knows that you don't sleep, Tom. You just sit back
in your chair and power nap for five minutes once in a while,
On Aug 4, 2009, at 6:30 PM, Tom Lane wrote:
Comments?
+1 Seems like a no-brainer.
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Jul 27, 2009, at 5:19 PM, David E. Wheeler wrote:
Yep, that's just what I needed, thanks. I think I'll send a patch
for the Cursors section of the PL/pgSQL documentation that
mentions this. Would have saved me a bunch of hassle.
So would have reading two more sentences of the docs
On Jul 26, 2009, at 4:02 PM, Eric B. Ridge wrote:
I'm just a random lurker, but FOUND seems to work just fine (I
suppose it's PG-specific?).
http://www.postgresql.org/docs/8.1/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-DIAGNOSTICS
BEGIN
OPEN stuff;
FETCH stuff INTO rec;
WHILE
On Jul 25, 2009, at 4:41 PM, David E. Wheeler wrote:
Useless perhaps, but it's gonna happen, and someone may even have a
reason for it. Until such time as NULLs are killed off, we need to
be able to deal with SQL's pathologies.
And something I'd like to be able to handle in a while loop
On Jul 25, 2009, at 9:24 AM, Jeff Davis wrote:
I don't think you want the NOT x IS NULL part at all -- that will
evaluate to false when x = rec(NULL,NULL). I think you just want the
x
IS DISTINCT FROM NULL part, right? Will that work?
Nope, infinite loop when because `ROW(null, null)` and
On Jul 25, 2009, at 9:42 AM, Kevin Grittner wrote:
I know that Codd was insistent that any relation (which included the
result of any query) which could contain duplicate rows should be
called a corrupted relation. (In fact, in one of his books I think
he averaged a comment on this point about
On Jul 23, 2009, at 9:34 PM, Brendan Jurd wrote:
Well, a ROW is an ordered set of values, each one of which may be
either NULL or NOT NULL.
Right.
It doesn't really make sense to talk about the ROW itself being NULL
or NOT NULL, only its member values (but for extra confusion, contrast
with
On Jul 24, 2009, at 3:17, Brendan Jurd dire...@gmail.com wrote:
ROW(NULL, NULL) IS NULL returns true, but that is not the
same as saying that it actually is NULL
I think my head just exploded. Loving the dark corners of SQL…
Best,
David
--
Sent via pgsql-hackers mailing list
On Jul 24, 2009, at 11:10, Tom Lane t...@sss.pgh.pa.us wrote:
Hmmm ... that suggests that we may not be handling IS DISTINCT FROM
correctly for rowtypes. I haven't read that part of the spec, but
I would've guessed that the spec wants it to be consistent with
IS NULL.
Yes, that's precisely
On Jul 24, 2009, at 9:40 AM, Jeff Davis wrote:
There's no single test, but you can see if it's an empty row with:
x IS NULL AND x IS DISTINCT FROM NULL
And you can see if it's a real NULL by:
x IS NULL AND x IS NOT DISTINCT FROM NULL
It's funny until you try it -- then it's just scary.
On Jul 24, 2009, at 11:37 AM, Jeff Davis wrote:
Hmmm ... that suggests that we may not be handling IS DISTINCT FROM
correctly for rowtypes. I haven't read that part of the spec, but
I would've guessed that the spec wants it to be consistent with
IS NULL.
Our behavior appears to match the
On Jul 24, 2009, at 2:59 PM, David E. Wheeler wrote:
FETCH have INTO rec_have;
FETCH want INTO rec_want;
WHILE NOT rec_have IS NULL OR NOT rec_want IS NULL LOOP
IF rec_have IS DISTINCT FROM rec_want THEN
RETURN false;
END IF;
rownum = rownum + 1
On Jul 22, 2009, at 11:17 AM, Andrew Gierth wrote:
To me (A) is looking like the obvious choice (the people smart enough
to be using hstore-new from CVS already can handle the minor pain of
updating the on-disk format).
Unless I hear any objections I will proceed accordingly...
Yes, that
On Jul 22, 2009, at 1:11 PM, Robert Haas wrote:
If you keep an old and a new version of the datatype, you can't
upgrade a tuple at a time, but you can at least upgrade one column at
a time, which is still better than a kick in the head.
And as long as you're willing to deprecate how far back
On Jul 22, 2009, at 11:46 AM, Dimitri Fontaine wrote:
Here are from memory the problems we don't have a solution for yet:
- how to give user the ability to install the extension's objects in
another schema than the pg_extension default one
Was that not a part of your original proposal, or
On Jul 23, 2009, at 1:08 AM, Dimitri Fontaine wrote:
Easy answer for first version: don't allow user to install extension
in
another place than what we think will better suit him, and that's the
new schema pg_extension, which always lies just before pg_catalog in
the
search_path.
Well, I
On Jul 23, 2009, at 2:11, Dimitri Fontaine dfonta...@hi-media.com
wrote:
Well the problem with that is if for example I define foo() and bar()
functions in my extension, and the user also has a foo() function in
his
own stuff (possibly lying in public, say).
Now if in my extenion in
On Jul 23, 2009, at 4:08, Robert Haas robertmh...@gmail.com wrote:
Yes... but if and just can paper over a good deal of complexity,
and it's not clear to me that there's any compensating advantage.
It seems reasonable not to worry about this issue in the first rev, or
at least not to let
On Jul 23, 2009, at 8:09 AM, Dimitri Fontaine wrote:
What about embedded calls in, say, plperl functions.
Hence the variable suggestion. In fact, it might go back to the idea
of subschemas, perhaps the name of the extension should be part of the
qualifying? I dunno, I'm just kind of
On Jul 23, 2009, at 9:09 AM, Andrew Dunstan wrote:
Please particularly see this sentence: But unless someone wants to
tackle that I think we should leave schema management entirely
alone, and leave it up to the extension author / DBA between them.
I think we are in some danger of massively
How can a record be neither NULL or NOT NULL?
try=# select ROW(1, NULL) IS NULL;
?column?
--
f
(1 row)
try=# select ROW(1, NULL) IS NOT NULL;
?column?
--
f
(1 row)
This makes it rather hard to tell, in PL/pgSQL, when I've fetched the
On Jul 23, 2009, at 3:19 PM, David E. Wheeler wrote:
How can a record be neither NULL or NOT NULL?
try=# select ROW(1, NULL) IS NULL;
?column?
--
f
(1 row)
try=# select ROW(1, NULL) IS NOT NULL;
?column?
--
f
(1 row)
This makes it rather hard
On Jul 23, 2009, at 4:08 PM, Tom Lane wrote:
This is per SQL standard. IS NULL is true if *all* the record's
fields are null; IS NOT NULL is true if *none* of them are.
Yeah, it's a bit dubious, but that's what they said.
And yet they're DISTINCT FROM each other if either or both contain
On Jul 23, 2009, at 3:33 PM, Jeff Davis wrote:
not ROW(1, NULL) is null and not ROW(1, NULL) is not null
I don't know what the SQL standard says about this
Thanks Jeff, that's just what I needed.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Jul 23, 2009, at 4:22 PM, Tom Lane wrote:
Dunno how you can possibly come to that conclusion. Those row
values are certainly distinct (according to both PG and the spec).
Are they not both null?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Jul 23, 2009, at 6:21 PM, Greg Stark wrote:
Are they not both null?
Isn't that just what you were complaining about not being the case:
Yes, but given that the standard says that `ROW(1, NULL)` is NULL,
then I would expect it to be NOT DISTINCT from `ROW(2, NULL)`.
Best,
David
--
On Jul 23, 2009, at 6:06 PM, Jeff Davis wrote:
However, in step 2, you transformed:
x IS NOT NULL = NOT x IS NULL
But in SQL that is not a tautology!
No, that's not the problem I see -- that solved the problem in my
particular code. The problem I see is that, given that the standard
On Jul 23, 2009, at 6:52 PM, David E. Wheeler wrote:
No, that's not the problem I see -- that solved the problem in my
particular code. The problem I see is that, given that the standard
says (according to Tom) that if any value is NULL then the record is
NULL, then I would expect
On Jul 22, 2009, at 8:55 AM, Andrew Gierth wrote:
The other option would be to fix the wasted-space bug in the existing
hstore, and document that stored data must be updated at least once
subsequent to that fix before doing a binary migrate to 8.5.
Given this…
(The pathological case is
On Jul 18, 2009, at 9:54 AM, Richard Huxton wrote:
No, it doesn't. David Wheeler's navigation (see upthread) that he
uses for the Bricolage docs does, however.
Ah, if you can change the overall layout then the world is your
shellfish of choice. Would it be possible to include jquery? It's
On Jul 16, 2009, at 12:49 PM, Andrew Dunstan wrote:
I'm using jQuery to pull the proper doc into a div. I'm still
noodling with it, trying to fix encoding issues on Windows, but
it's pretty close to done.
Yes, that's nice, it's just the sort of thing I had in mind - if you
can do it with
On Jul 14, 2009, at 3:21 PM, Andrew Dunstan wrote:
Yes, really. What you suggest here is just not adequate, IMNSHO. I
don't want to have to scroll to the top or bottom of the page to get
navigation, and I want to be able to see the navigation and go where
I want directly.
Hey Andrew,
On Jul 16, 2009, at 7:17 AM, Andrew Gierth wrote:
Revision to previous hstore patch to fix (and add tests for) some edge
case bugs with nulls or empty arrays.
This looks great, Andrew, thanks. Here's what I did to try it out:
* I built a simple database with a table with an (old) hstore
On Jul 10, 2009, at 4:01 PM, Josh Berkus wrote:
All,
I'd suggest that we publish an official policy, with the following
dates for EOL:
7.4 2009-08-01
8.0 2010-02-01
8.1 2011-01-01
8.2 2012-01-01
8.3 2013-03-01
8.4 2014-08-01
EOL would be defined as:
After the above dates, the
On Jul 10, 2009, at 5:39 PM, Tom Lane wrote:
I don't mind the idea of saying our intention is to support new
releases for about five years, or something equally squishy.
But a list of dates in black and white does not look reasonable,
especially not dates that are four or five years out for
On Jul 7, 2009, at 12:49 AM, Albe Laurenz wrote:
Is this a known issue in 8.3? If so, is there a known workaround?
The change is probably here:
http://archives.postgresql.org/pgsql-committers/2008-10/msg00110.php
So I think it is safe to argue that this is not a bug in 8.3, but an
On Jul 7, 2009, at 8:06 AM, Tom Lane wrote:
I'd personally be perfectly happy with a community decision to
desupport
7.4 now, or perhaps after the next set of update releases (which we're
probably overdue for, BTW). We cannot support an indefinitely large
set
of back branches, and a
On Jul 7, 2009, at 9:13 AM, Andrew Dunstan wrote:
One thing I think we really should do is give prominent public
notice of any EOL for a branch. At least a couple of months,
preferably. If the lifetime were absolutely fixed it might not
matter so much, but as it isn't I think we owe that
On Jul 7, 2009, at 10:18 AM, Alvaro Herrera wrote:
We have an RSS:
http://www.postgresql.org/versions.rss
Does anyone use it? And it only goes back to 8.0 and it served with
the text/html content-type.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Jul 7, 2009, at 11:59 AM, Alvaro Herrera wrote:
And it only goes back to 8.0
Huh, true :-( This should be fixed.
Yeah. Or we should have a table. I could create one in the wiki, I
guess, but I would assume that the core team would want to have formal
control over scheduled
On Jul 7, 2009, at 12:59 PM, Alvaro Herrera wrote:
Yeah. Or we should have a table. I could create one in the wiki, I
guess, but I would assume that the core team would want to have
formal
control over scheduled maintenance expirations…
The web team already has a table, and it is published
Howdy Hackers,
Is there a published maintenance policy somewhere? Something that says
for how long the project supports minor releases of PostgreSQL. For
example, does 7.4 still get bug fixes and minor releases? If not, how
does one know when support for a major version has been dropped?
On Feb 6, 2009, at 10:54 AM, David E. Wheeler wrote:
On Feb 6, 2009, at 9:43 AM, Bruce Momjian wrote:
Oh. That seems kind of odd?can you hang onto the patch until 8.4 is
released, then? This must happen all the time, no?
OK, I will hang on to it, but I will have to mention it is only
On Jul 1, 2009, at 9:07 AM, Tom Lane wrote:
Just a reminder, Bruce, to add the CITEXT bit to the FAQ when 8.4 is
released. Is that supposed to be today?
The FAQ is on the wiki now ... fix it yourself.
It is? When did that happen?
Best,
David
--
Sent via pgsql-hackers mailing list
On Jul 1, 2009, at 9:27 AM, Tom Lane wrote:
It is? When did that happen?
http://archives.postgresql.org/pgsql-committers/2009-04/msg00111.php
Thanks. Change added to the wiki.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
This code:
CREATE OR REPLACE FUNCTION foo() returns boolean as $$
DECLARE
have_rec record;
want_rec record;
BEGIN
have_rec := row(1, 2);
want_rec := row(3, 5);
RETURN have_rec IS DISTINCT FROM want_rec;
END;
$$ language plpgsql;
On Jul 1, 2009, at 11:47 AM, Merlin Moncure wrote:
fyi: works in 8.4, as part of a broad fix of composite type
comparison ops
whoops, you knew that already :-). one possible workaround is:
select $1::text is distinct from $2::text
Yes, and that's what I'm doing, although it is
Howdy,
I'm working on functions to compare result sets for pgTAP. In the
process, I found what appears to be an inconsistency in error handling
when comparing incomparable results. I'm testing in 8.4RC2, but the
issue may go back for all I know. Perhaps it's intentional?
This is what I
On Jun 30, 2009, at 10:28 AM, Tom Lane wrote:
VALUES (1, 2), (3, 4) EXCEPT VALUES (1), (3);
Throws 42601 SYNTAX ERROR.
Not for me:
regression=# VALUES (1, 2), (3, 4) EXCEPT VALUES (1), (3);
ERROR: each EXCEPT query must have the same number of columns
Turn on verbosity:
try=# \set
]On Jun 30, 2009, at 11:00 AM, Tom Lane wrote:
Oh, you're complaining about the SQLSTATE not the error text.
I guess that to the extent that any actual thought went into it
(which may not have been much) the reasoning was that you'd have to
change the syntax of your query in order to fix this.
On Jun 30, 2009, at 11:18 AM, Tom Lane wrote:
So really what you're wishing for is that we treat different-numbers-
of-
columns as a whole new SQLSTATE inside category 42. What's the
argument
for needing to handle this differently from DATATYPE_MISMATCH?
For my results_eq() in pgTAP, it
On Jun 30, 2009, at 11:27 AM, David E. Wheeler wrote:
# Failed test 148
# Number of columns differs between queries
# have: 4 columns
# want: 3 columns
# Failed test 149
# Column types differ between queries
# have: (integer,text
On Jun 30, 2009, at 11:46 AM, Tom Lane wrote:
For my results_eq() in pgTAP, it could output different diagnostics.
Well, that's not terribly compelling ;-).
Pllt.
I wouldn't have any big
objection to splitting out ERRCODE_COLUMN_COUNT_MISMATCH as a separate
SQLSTATE for 8.5 and
On Jun 30, 2009, at 11:48 AM, Tom Lane wrote:
Is there a way
to get a RECORD object to tell me what data types it contains?
Not at the SQL level. Of course, if you're writing C, you can do
something similar to what record_eq and friends do.
Pity. I'm trying to keep C out of pgTAP (for the
On Jun 30, 2009, at 11:54 AM, David Fetter wrote:
# Failed test 148
# Number of columns differs between queries
# have: 4 columns
# want: 3 columns
Shouldn't that just read:
have: (int, int, text, point)
want: (int, int, text)
Yes, that's my ideal, but
On Jun 30, 2009, at 1:40 PM, David Fetter wrote:
Yes, that's my ideal, but Tom says I need to write C code to get that
information from RECORD objects, alas. :-(
Would this be the first C piece? If not, it might be worth doing.
I don't understand the question. But yes, I think it'd be
On Jun 30, 2009, at 3:05 PM, David Fetter wrote:
Would this be the first C piece? If not, it might be worth doing.
I don't understand the question.
I was thinking of this as part of PgTAP.
Oh. There is a piece of C, but it's just an implementation of
pg_typeof() so that pgTAP can use
On Jun 25, 2009, at 2:21 AM, Dave Page wrote:
Is it possible to design this part of the extension system with only
PGXS in mind and later adapt the windows toolsuite?
Anything is possible :-). Better to ask someone with more perl
expertise than me how much effort it might take to have the
On Jun 25, 2009, at 7:16 AM, Tom Lane wrote:
The problem is, I think, that the Makefile format is way too
flexible.
I think the contrib makefiles are considered to be our standard test
suite for PGXS. If a 3rd-party makefile is doing anything not
represented in contrib, it's not guaranteed
On Jun 25, 2009, at 10:10 AM, Tom Lane wrote:
Is there no platform-independent build system we could take advantage
of?
There's been some talk of using cmake, but the conversion effort would
be massive, and I'm not sure the benefits would warrant it.
Might it be worthwhile just for the
On Jun 24, 2009, at 12:59 AM, Dimitri Fontaine wrote:
are you aware of the enormous job that will imply for core team?
I'm not saying I want core to take care of all pgfoundry projects that
will make them available as extensions, but to have contrib/ made
extensions and have core if possible
On Jun 24, 2009, at 2:07 PM, Andrew Dunstan wrote:
Actually, I think we should be like Perl here. There is a list of
standard modules that comes with the base Perl distro, and then
there are addons, such as you find on CPAN.
Actually, the lesson slowly emerging in the Perl community is
On Jun 24, 2009, at 2:12 PM, Dimitri Fontaine wrote:
The core team isn't appropriate for this. We'd start a new
committee/list somewhere instead, and it would be part of the same
effort which produces a recommended list of extensions and
drivers for packagers.
It'd still deprecate
On Jun 24, 2009, at 2:41 PM, Andrew Dunstan wrote:
I agree they have too many. I think moving to none would be a
mistake, though. Would they even drop things like Dynaloader or
ExtUtils::MakeMaker? That would be crazy, IMNSHO. I think there's a
sweet spot here and we are not very far away
On Jun 24, 2009, at 3:09 PM, Andrew Dunstan wrote:
Well, I think in our case that would be going too far. I think there
is a very good case for keeping a few key extensions in core both as
exemplars and to make it easy to validate the extension mechanism
itself. There have been suggestions
On Jun 24, 2009, at 3:41 PM, Andrew Dunstan wrote:
We have been conservative about this in the past and there is no
reason to expect we will not be in the future. If anything, we are
likely to become more so.
Good, perfect.
Best,
David
--
Sent via pgsql-hackers mailing list
On Jun 23, 2009, at 6:25 AM, Tom Lane wrote:
We spun an 8.4RC2 tarball, mainly to check that Peter's recent fixes
to the man page generation process actually worked. There will not be
binary builds of RC2, but if anyone who's building from source wants
to
double check it, it should be on
On Jun 23, 2009, at 10:44 AM, Dimitri Fontaine wrote:
The contenders are extension, module, bundle and package. My vote is
extension.
+1
== v1.0 goals
We're not trying to be feature complete on first round.
* must have
- dump restore support (when upgrading a cluster or just restoring)
On Jun 23, 2009, at 2:06 PM, Dimitri Fontaine wrote:
It'd be nice if it supported other core languages like PL/Perl, but
it's okay if it doesn't on the first round (I'd likely want to use
some CPAN modules in a PL/Perl extension, anyway).
At first sight I though you were talking about a
1101 - 1200 of 1565 matches
Mail list logo
