On Sep 28, 2006, at 16:39, Jim C. Nasby wrote:
+1. I was just at a client today that had run into this problem.
Actually, I'm in favor of refusing to start if autovac is on but the
proper stats settings aren't. I'd rather that then people ending up
with
bloated databases and crappy
Howdy,
I'm trying to write a simple function that will return a string with
the type name of a value. Unfortunately, it keeps dying on me. I don't
even get any useful debugging information with --enable-cassert, just
this:
LOG: server process (PID 96946) was terminated by signal 10: Bus
On Sep 1, 2008, at 16:55, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
Here's the complete code:
Looks like you forgot PG_FUNCTION_INFO_V1(), so what's being passed to
this isn't an fcinfo ...
Bah! I knew I had to be missing something really fundamental. Thanks
Tom.
BTW
On Sep 1, 2008, at 22:31, Brendan Jurd wrote:
Oh, another thing: it shouldn't be STRICT. Nulls have perfectly good
types.
Agreed.
Barring any further comments/objections, I'll go ahead and prepare a
patch to add this to core.
So it will return a text representation or an Oid?
Best,
On Sep 2, 2008, at 08:58, David E. Wheeler wrote:
On Sep 1, 2008, at 22:31, Brendan Jurd wrote:
Oh, another thing: it shouldn't be STRICT. Nulls have perfectly
good
types.
Agreed.
Barring any further comments/objections, I'll go ahead and prepare a
patch to add this to core.
So
On Sep 2, 2008, at 10:43, David E. Wheeler wrote:
Looks like regtype displays as an integer. So how about
pg_regtypeof() and pg_typeof()?
Sorry, make that:
PG_FUNCTION_INFO_V1(pg_regtypeof);
Datum
pg_regtypeof(PG_FUNCTION_ARGS)
{
PG_RETURN_OID(get_fn_expr_argtype(fcinfo-flinfo, 0
On Sep 2, 2008, at 11:06, Tom Lane wrote:
Better try that again.
regression=# select 1043::regtype;
regtype
---
character varying
(1 row)
regression=#
I see no need for two functions here.
Oh. I tried:
try=# select 1::regtype;
regtype
-
1
I had assumed that
On Sep 4, 2008, at 21:40, Ryan Bradetich wrote:
Overall I think the patch looks good. After reviewing the patch, I
played with
citext for an hour or so and I did not encounter any bugs or other
surprises.
Thanks for the review, Ryan!
Best,
David
--
Sent via pgsql-hackers mailing list
On Sep 5, 2008, at 11:30, Tom Lane wrote:
Thanks for reviewing. I've committed this with your suggestions and
one additional non-cosmetic change: schema-qualify names in the
bodies of the SQL functions so that they are not search_path
dependent.
Thanks, I'll check that out.
One thing
On Sep 5, 2008, at 11:33, David E. Wheeler wrote:
On Sep 5, 2008, at 11:30, Tom Lane wrote:
Thanks for reviewing. I've committed this with your suggestions and
one additional non-cosmetic change: schema-qualify names in the
bodies of the SQL functions so that they are not search_path
On Sep 12, 2008, at 10:58, Tom Lane wrote:
1. Did I neglect to include the documentation patch? I've attached it
here. It's necessary because of the addition of the new functions.
Maybe it got left out of the later patch iterations? Anyway,
will take care of it.
Great, thank you.
2. Many
On Sep 12, 2008, at 11:06, David E. Wheeler wrote:
Er, look into pg_cast and then pg_proc? For instance
select oid::regprocedure, prosrc from pg_proc
where oid in (select castfunc from pg_cast);
That looks like *exactly* what I need. Thanks!
Pity. Looks like there were only a few I
On Sep 12, 2008, at 11:14, David E. Wheeler wrote:
Pity. Looks like there were only a few I wasn't using, text_char,
char_text, text_name, and texttoxml.
Oh, and text_name seems to give me this error:
ERROR: compressed data is corrupt
That's when I have this cast:
CREATE OR REPLACE
On Sep 12, 2008, at 11:31, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
Oh, and text_name seems to give me this error:
ERROR: compressed data is corrupt
That's when I have this cast:
CREATE OR REPLACE FUNCTION citext(name)
RETURNS citext
AS 'text_name'
LANGUAGE
On Sep 12, 2008, at 11:34, Tom Lane wrote:
CREATE OR REPLACE FUNCTION int8(citext)
RETURNS int8
AS 'SELECT int8( $1::text )'
LANGUAGE SQL IMMUTABLE STRICT;
Yeah, those are all replaced by the CoerceViaIO mechanism
Okay, thanks for the sanity check. The SQL versions are fine for me in
8.3.
On Sep 12, 2008, at 11:35, David E. Wheeler wrote:
I've got another patch I'm working on adding support for char (and
tests for char). Just to fill out a gap I saw in the casting
coverage. I'm trying to get it done now. With that, AFAIK, citext
will work just like text.
Looks like the IO
On Sep 12, 2008, at 12:49, Alvaro Herrera wrote:
Looks like the IO conversions handle char and char, so the attached
patch just updates the regression test.
There are unresolved conflicts in the patch ...
Bah! Sorry. Let me try that again.
Best,
David
char_tests.patch
Description:
On Sep 18, 2008, at 07:38, Tom Lane wrote:
I wasn't intending to start a discussion about how/when to EOL 7.4,
but since the thread has gone in that direction: my vote would be to
announce now (say, with the announcement of this set of releases) that
7.4 will be EOL'd with our first set of
Howdy,
Not *exactly* hackers-related, but I wanted to get a feel for this
from those who are likely to use project hosting, and to minimize the
chances of a flame war.
Right now I have pgTAP on pgFoundry, which is okay, though it appears
to be largely unmaintained. PostgreSQL module
On Sep 18, 2008, at 11:27, Joshua Drake wrote:
* LaunchPad
Is backed by PostgreSQL. It is the only logical choice :). Seriously
though it is a good service.
Looks pretty nice, though it doesn't have project home pages. Having
just created one for pgTAP on pgFoundry, I'd
On Sep 18, 2008, at 18:43, Robert Treat wrote:
* Google Code
does not offer mailing lists
I get mail for the test-more project there. It's through Google
Groups, which is a little weird, but works.
* LaunchPad
does not offer svn or git, and i think they dont offer a home page
On Sep 18, 2008, at 19:01, Alvaro Herrera wrote:
Why not host the code on (say) GitHub, and the rest of the stuff on
pgFoundry?
That's kind of what I'm doing now. But I'm wondering if I should
bother with pgFoundry at all. It seems pretty dead (see Josh Berkus's
reply).
Best,
David
On Sep 19, 2008, at 01:25, Dimitri Fontaine wrote:
There's a french non-profit team offering those:
http://tuxfamily.org/en/main
You can even take their open source hosting facility software and
offer your
own services based on it, and/or extend their perl code to add new
features.
I
On Sep 22, 2008, at 10:08, Stefan Kaltenbrunner wrote:
The machine is ready to go and as far as I know even has a jail.
Stefan
would know more.
OK, cool. Stefan; what's your take on where we're at?
yeah there is a box and a jail I set up a while ago but for various
reasons the actual
On Sep 24, 2008, at 14:02, Joshua Drake wrote:
I think one problem we have right now, is nobody knows what it is
going
to take. I would expect that our current version is sufficiently old
enough to cause some migration pain?
I know we have two members willing to help that are not Stefan and
On Sep 25, 2008, at 20:45, Tom Lane wrote:
Well, there are two possible interpretations: (1) it's a bug, or (2)
it's an intentional, about-to-be-documented feature that
backslashing a
letter makes it case-sensitive in ILIKE.
I do not care for interpretation #2 ... especially in view of your
On Sep 28, 2008, at 17:46, Tom Lane wrote:
BTW, I think it is (or should be) possible to create an index on
hstore-'mycol', so at least one of the reasons why you should *need*
to switch to a real database column seems bogus.
The docs say:
titleIndexes/title
para
typehstore/ has
On Sep 28, 2008, at 23:46, [EMAIL PROTECTED] wrote:
I'm not sure what that means. Can you create normal btree or hash
indexes
on hstore columns? And is the index useful for both `@` and `?`?
That means that those operations are supported by a GiST (or GIN)
index,
that is:
find the
Just want to make sure that this wasn't lost in the shuffle somewhere…
Best,
David
On Sep 14, 2008, at 15:42, David E. Wheeler wrote:
On Sep 12, 2008, at 12:49, Alvaro Herrera wrote:
Looks like the IO conversions handle char and char, so the
attached
patch just updates the regression test
On Oct 10, 2008, at 20:27, Joshua Tolley wrote:
Now, if you want to fix psql so that even with a semicolon there it
will redisplay the command buffer and wait for a return, then I'd
agree
that that's an improvement. I couldn't figure out how to get
readline
to cooperate with that ... but
Howdy,
Any interest in adding a function like this to core?
Datum
pg_version(PG_FUNCTION_ARGS)
{
PG_RETURN_INT32(PG_VERSION_NUM);
}
That returns an integer, such as
try=# select pg_version();
pg_version
80304
(1 row)
I've whipped this up for pgtap, as it'll be useful
On Oct 11, 2008, at 19:57, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
Any interest in adding a function like this to core?
No, because it's already there: see show server_version_num.
(It's probably worth noting that none of our existing clients that
would
have any use
On Oct 12, 2008, at 11:21, Magnus Hagander wrote:
Yeah, but I want to use it in WHERE clauses or CASE statements. I'm
fine
to just include it in pgtap, though.
You could do:
select setting from pg_settings where name='server_version_num';
(wrapped in the appropriate subselect to use it in
On Oct 12, 2008, at 12:42, Tom Lane wrote:
Yeah, but I want to use it in WHERE clauses or CASE statements.
current_setting('server_version_num')
Hrm. That's nice. I don't suppose there's any way to get something
like that in 8.1 and earlier? I was going to fake it in the .c file.
On Oct 12, 2008, at 14:11, Tom Lane wrote:
You'd have to parse the result of version().
As I figured. This is what I'm trying:
pg_version_num(PG_FUNCTION_ARGS)
{
#ifdef PG_VERSION_NUM
PG_RETURN_INT32(PG_VERSION_NUM);
#else
/* Code borrowed from dumputils.c. */
int
On Oct 12, 2008, at 20:15, Joshua D. Drake wrote:
Yeah I would agree with that. I find that only real issue with
PgFoundry is the PgFoundry (aka Gforge) not the quality of the
projects being hosted.
The other thing that could use some love is searching for projects.
Google doesn't rank
Howdy,
Not sure if PostgreSQL uses time_t, but if so, this project provides
useful code (a drop-in replacement for time.h) to address the 2038 bug
on 32-bit platforms.
http://code.google.com/p/y2038/
Useful for PostgreSQL?
Best,
David
--
Sent via pgsql-hackers mailing list
On Oct 13, 2008, at 11:01, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
Not sure if PostgreSQL uses time_t,
We got rid of that some time ago.
Probably no problem, then. Do dates in PostgreSQL work for their
entire documented ranges on 32bit processors?
Thanks,
David
On Oct 13, 2008, at 11:13, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
Probably no problem, then. Do dates in PostgreSQL work for their
entire documented ranges on 32bit processors?
As long as the C compiler supports int64 ...
I was afraid you'd say that. See:
http
On Oct 13, 2008, at 11:22, Zdenek Kotala wrote:
PostgreSQL 8.4 uses 64bit data type for time. But if you use system
timezone then you can get in trouble if system does not support
64bit zic files.
I've never noticed a problem with the TZinfo database that ships on
systems I've used. How
On Oct 13, 2008, at 11:24, Andrew Chernow wrote:
PostgreSQL doesn't use the standard time_t and time functions for
its timestamp types. Therefore, any limitations in regards to 64-
bit time_t values on 32-bit platforms don't apply; other than the
limitation Tom spoke of ... no 64-bit int.
On Oct 13, 2008, at 11:37, Zdenek Kotala wrote:
when you use --with-system-tzdata and run make check on head it
fails on systemes without 64bit tzinfo support.
Oh. Is it not preferable to use the tzdata that ships with PostgreSQL?
Thanks,
David
--
Sent via pgsql-hackers mailing list
On Oct 13, 2008, at 11:53, Tom Lane wrote:
Oh. Is it not preferable to use the tzdata that ships with
PostgreSQL?
Not necessarily; the system might have a more up-to-date tzdata.
Gotcha.
Generally you'd use --with-system-tzdata on a platform where you
expect
to receive routine package
On Oct 13, 2008, at 12:35, Zdenek Kotala wrote:
Tom Lane napsal(a):
Generally you'd use --with-system-tzdata on a platform where you
expect
to receive routine package updates for the tzdata files,
independently
of the Postgres release cycle. It seems reasonable to assume that
anyone
Well, the C version I borrowed from dumpitils seems to work great. Any
reason I shouldn't stay with that?
Best,
David
Sent from my iPhone
On Oct 14, 2008, at 7:44, Hannu Krosing [EMAIL PROTECTED] wrote:
On Sun, 2008-10-12 at 14:39 -0700, David E. Wheeler wrote:
On Oct 12, 2008, at 14:11
On Oct 14, 2008, at 08:33, David E. Wheeler wrote:
Well, the C version I borrowed from dumpitils seems to work great.
Any reason I shouldn't stay with that?
Also, here's a simpler SQL version, for those following along at home:
create or replace function pg_version_num() returns int
On Oct 14, 2008, at 12:36, Alvaro Herrera wrote:
I don't know if you have noticed, but the spoonbill buildfarm member
is
failing the citext test. Unfortunately the regression diff is not
very
helpful:
Binary files /home/pgbuild/pgbuildfarm/HEAD/pgsql.2397/contrib/
On Oct 14, 2008, at 14:00, Stefan Kaltenbrunner wrote:
well what we are looking at here are actually two issues - one is
the regression failure - diff -a produces:
http://www.kaltenbrunner.cc/files/citext.diff.txt
Am I reading that right? Is there really just an issue of a different
On Oct 14, 2008, at 14:32, Hannu Krosing wrote:
On Tue, 2008-10-14 at 08:33 -0700, David E. Wheeler wrote:
Well, the C version I borrowed from dumpitils seems to work great.
Any
reason I shouldn't stay with that?
SQL is the only PL available by default, no need to compile or
install
On Oct 14, 2008, at 14:50, Hannu Krosing wrote:
Was current_setting('server_version') available in 8.1 ?
Yes. In 8.0, too.
There must be a way to get string_to_array() to evaluate only once,
yes?
SELECT s.a[1]::int * 1 + s.a[2]::int * 100 + s.a[3]::int
FROM
(SELECT
On Oct 21, 2008, at 12:08, Simon Riggs wrote:
Please remove zero-dimension arrays.
The number of dimensions of an empty array really ought to be NULL, or
if we fix it to be non-NULL then 1+. Zero just makes a weird case
for no
reason. An empty string only makes sense in the context of that
On Oct 21, 2008, at 13:00, Andrew Chernow wrote:
On Oct 21, 2008, at 12:08, Simon Riggs wrote:
If we got rid of zero dimension arrays, how would I declare a new
empty array in a PL/pgSQL function?
Why would you want to do that? Is there a use case for that?
Perhaps not. In older versions
On Oct 21, 2008, at 13:58, Tom Lane wrote:
If we got rid of zero dimension arrays, how would I declare a new
empty array in a PL/pgSQL function?
Same as before, I think: initialize it to '{}'. What's at stake here
is exactly what does that notation mean ...
An empty, single-dimension
On Oct 21, 2008, at 14:16, Tom Lane wrote:
Well, we can't do that because it would clearly break too much
existing
code. '{}' has got to result in something you can successfully
concatenate more elements to.
Right, that's what I was trying to day. Badly, I guess.
But either the current
On Oct 22, 2008, at 00:40, Simon Riggs wrote:
An empty, single-dimension array. But I got the impression from Simon
that he thought it should be NULL.
I meant the dimension of {} should be NULL.
To me that's 0.
Best,
David
--
Sent via pgsql-hackers mailing list
[Re-sending to hackers, since the original message to pgsql-bugs has
not been approved for delivery in the last four days…apologies for any
duplicates.]
Howdy,
I ran into this error on 8.2 a while ago, and just figured out what
was causing it. Here's a quick example on 8.2:
BEGIN;
--
On Nov 3, 2008, at 1:28 AM, Kurt Harriman wrote:
2) func.sgml: clarifying that the function returns an OID rather
than a string
Actually, it returns a regtype, no?
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Nov 3, 2008, at 10:02 AM, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
On Nov 3, 2008, at 1:28 AM, Kurt Harriman wrote:
2) func.sgml: clarifying that the function returns an OID rather
than a string
Actually, it returns a regtype, no?
I thought the description was good
On Nov 3, 2008, at 10:52 AM, Alvaro Herrera wrote:
Give this a read
http://www.postgresql.org/docs/8.3/static/datatype-oid.html
Yeah.
Maybe we should link to this page in the pg_typeof() description.
Also,
perhaps this page needs more examples.
Yes, both of those would help a lot, I
On Nov 5, 2008, at 6:40 AM, Kenneth Marshall wrote:
I installed and ran the citext tests both with and without
the patch and had failures both times. The patch applied
cleanly and the make;make install completed without errors.
I have attached the two regression.diffs files, one without
the
On Nov 5, 2008, at 12:34 PM, Kenneth Marshall wrote:
I am using the anonymous CVS repository, it returns the following
information in pg_catalog.pg_settings:
What is lc_collate set to?
% show lc_collate;
FWIW, I just ran the tests myself and all passed, with and without the
patch (using
On Nov 3, 2008, at 11:15 AM, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
On Nov 3, 2008, at 10:52 AM, Alvaro Herrera wrote:
Maybe we should link to this page in the pg_typeof() description.
Also,
perhaps this page needs more examples.
Yes, both of those would help a lot, I
On Nov 7, 2008, at 10:43 AM, Kenneth Marshall wrote:
Thank you for the pointers. lc_collate is set to en_US.UTF-8.
Huh. Same as for me.
I re-initdb the database with the --no-locale option and then the
tests passed successfully. Thank you for the reminder that the
regression tests need to
On Nov 7, 2008, at 11:15 AM, Tom Lane wrote:
In a quick test on a Fedora box, citext is the only core or contrib
test
that fails in en_US. (This is true in HEAD, even without having
applied
the proposed patch.) It would be good to clean that up.
Huh. There must be something different
On Nov 7, 2008, at 11:50 AM, Tom Lane wrote:
This is why I like TAP.
And how would TAP reduce the number of expected results?
TAP doesn't compare output to expected output files. It's simply a
test result output stream. A separate program then harnesses that
output, looks at what passed
On Nov 7, 2008, at 12:12 PM, Tom Lane wrote:
... and you have very limited visibility into what went wrong, if
anything goes wrong. That's not real attractive for the buildfarm
environment. I like being able to see the actual query output.
It depends on how you write it - you can add a lot
On Nov 7, 2008, at 2:55 PM, Tom Lane wrote:
Well, I wasn't sure of the appropriate place to add examples to
datatype.sgml. But this patch would certainly make the output of
pg_typeof() much clearer to newbies like me.
Applied with some further editorialization.
Thanks!
David
--
Sent via
On Nov 7, 2008, at 3:18 PM, Tom Lane wrote:
Agreed, but I admit to being mystified as to why things would be
sorting any differently on darwin vs. Fedora. I kept everything in
ASCII, on your advice, to keep from having to deal with crap like
this.
Patch applied with this adjustment.
On Nov 10, 2008, at 8:03 AM, Tom Lane wrote:
We should probably standardize on the perl version, ugly or not,
because
otherwise we'll have a difference in build process between Unix and
Windows machines. Personally I don't really care how ugly it is as
long
as no one has to look at it ;-)
On Nov 10, 2008, at 11:17 AM, Andrew Dunstan wrote:
David, how is your awk-fu? If it's any good then I'm happy to leave
it to you. Otherwise I will try to make a few hours somewhere to un-
uglify this.
My Perl is excellent, but my awk is remedial. What part does awk play?
Best,
David
--
On Nov 19, 2008, at 9:12 AM, Josh Berkus wrote:
Folks,
Since it's too late to look at this for 8.4, can the following go on
the TODO list?
Referential Integrity
[] Allow creation of FKs targeting unique expression indexes on the
referenced table. Syntax: REFERENCES reftable ( ( column
On Nov 28, 2008, at 12:46 PM, Peter Eisentraut wrote:
I understand, but the work required to make it work properly is too
much under the commit fest spirit right now. In particular, I'm
thinking we should try to devise a clever way to make the CREATE
ORDERING facility that SQL has for
On Nov 28, 2008, at 5:09 PM, Andrew Dunstan wrote:
Speaking of other sorts of derived types: might they include
something just like enums, but sorting on the string values defined
for the enum rather than on the order in which the values were
defined in the enum? I'd use something like
On Nov 30, 2008, at 6:49 PM, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
There are two ways to fix this, both having some validity:
1. We create a second version of pg_get_function_arguments() that
produces
arguments without default values decoration. This is probably the
On Dec 1, 2008, at 1:08 PM, Heikki Linnakangas wrote:
postgres=# SELECT to_timestamp('29-12-2005 01:02:3', 'DD-MM-
HH24:MI:SS'); -- doesn't work
ERROR: source string too short for SS formatting field
DETAIL: Field requires 2 characters, but only 1 remain.
HINT: If your source string is
On Dec 1, 2008, at 3:52 PM, Tom Lane wrote:
I'm generally in favor of being generous in the input one can accept,
but in this case it seems ambiguous to me. Is that supposed to be :30
or :03? There's no way to tell.
But notice that we are allowing a single digit for the hour and minute
On Dec 1, 2008, at 3:55 PM, Dave Page wrote:
I'm generally in favor of being generous in the input one can
accept, but in
this case it seems ambiguous to me. Is that supposed to be :30 or :
03?
There's no way to tell.
How is it ambiguous? The leading zero is technically redundant. A
On Dec 1, 2008, at 4:07 PM, Alvaro Herrera wrote:
David E. Wheeler wrote:
Oh, well yeah, it should be consistent. But I'm still not sure
that :3
should be allowed. OTOH, who does that, anyway?
Anyone who prints times as %d:%d:%d. You can find those in the wild.
I guess I should have
On Dec 1, 2008, at 4:09 PM, Dave Page wrote:
On Mon, Dec 1, 2008 at 3:02 PM, David E. Wheeler
[EMAIL PROTECTED] wrote:
it depends on how you look at it, I suppose. If you look at :xy
as x
being the 10s position and y being the 1s position, it makes no
sense.
Suffice it to say, I don't
On Dec 8, 2008, at 2:46 AM, Tom Lane wrote:
Comments?
+1
If this is agreed to be a bug, should we consider
back-patching it? (I'd vote not, I think, because the behavioral
change could conceivably break some apps that work now.)
+1
Best,
David
--
Sent via pgsql-hackers mailing list
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-sql-ish.
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 a
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
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 error
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.
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 defined and
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
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
discussed
From: David E. Wheeler da...@justatheory.com
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 `type
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:
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
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
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-hackers
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-hackers
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
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
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
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 in
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 absolutely
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 changes
1 - 100 of 1565 matches
Mail list logo
