On Sep 15, 2009, at 11:01 AM, Andrew Gierth wrote:
If you want to store both a timestamp and an associated timezone you
can do
it right now, using a composite type or two columns, with the
advantage that
you get semantics that you can rely on.
How would a composite work in practice? Can
On Sep 15, 2009, at 8:31 PM, Andrew Gierth wrote:
Gah. rerolled to fix a missing file. includes the docs too this time.
Yay, thank you Andrew! Here are my review notes.
Testing
===
Here's what I did to try out the patch, paying special attention to in-
place upgrading:
* I built a
On Sep 19, 2009, at 7:03 PM, Tom Lane wrote:
Given the number of questions in your review, I don't think this is
actually ready to commit. I'm marking it waiting on author instead.
Yes, actually, I had second thoughts about that and meant to change it
myself. Thanks Tom.
David
--
Sent
On Sep 18, 2009, at 6:27 PM, Andrew Gierth wrote:
However, I would prefer to keep the ability to do this:
psql --set hstore_schema='myschema' -f hstore.sql dbname
The logic to do it is a bit ugly, but editing the file to set what
schema to
use is even uglier...
Yes, this should perhaps
On Sep 20, 2009, at 8:43 AM, Tom Lane wrote:
If the perfect solution is too complex, I'd also kinda hope this
isn't a
show-stopper for this patch, but rather a TODO for the future
modules feature.
Yeah, this is a long-standing generic issue, and not really hstore's
problem to fix.
So
On Sep 20, 2009, at 1:03 AM, Andrew Gierth wrote:
I will resubmit (hopefully in a day or two) with the following
changes:
- removal of the \set schema variable stuff from the .sql script
- documentation fixes as mentioned in my previous email
- additional documentation for some of the newer
On Sep 20, 2009, at 3:14 PM, Andrew Gierth wrote:
I think you're missing the point here; I can't control what it
resolves
to, since that's the job of the function overload resolution code.
Yeah, but I think that the existing behavior is probably the best.
But I checked, and
On Sep 20, 2009, at 12:15 PM, Tom Lane wrote:
That recipe doesn't actually work for cases like this. What *would*
work is loading the module *before* restoring from your old dump,
then relying on the CREATEs from the incoming dump to fail.
Jesus this is hacky, either way. :-(
I believe we
On Sep 21, 2009, at 4:57 PM, Andrew Gierth wrote:
I don't think there's any way to do that from the regression tests.
The output that you demonstrated a few messages back should do nicely
for delete(), at least:
contrib_regression=# explain verbose select delete(('a' =
Hackers,
I just had a discussion on IRC about unicode normalization in
PostgreSQL. Apparently there is not support for it, currently. Andrew
Gierth points out that it's part of the SQL spec to support it, though:
RhodiumToad:e.g. NORMALIZE(foo,NFC,len)
justatheory:Oh, just a function
On Sep 23, 2009, at 11:08 AM, David E. Wheeler wrote:
I just had a discussion on IRC about unicode normalization in
PostgreSQL. Apparently there is not support for it, currently.
BTW, the only reference I found on the [to do list](http://wiki.postgresql.org/wiki/Todo
) was:
More sensible
On Sep 23, 2009, at 11:08 AM, David E. Wheeler wrote:
I looked around and found the Public Software Group's utf8proc
project, which even includes some PostgreSQL support (not, alas, for
normalization). It has an MIT-licensed C library that offers these
functions:
Sorry, forgot the link
On Sep 22, 2009, at 7:18 PM, Andrew Gierth wrote:
Hstore patch incorporating changes as previously discussed.
In addition the requested new features of conversions to and from
array formats have been added (with docs).
Thanks Andrew.
Just a few thoughts for discussion:
* From my previous
On Sep 24, 2009, at 6:24 AM, p...@thetdh.com wrote:
In a context using normalization, wouldn't you typically want to
store a normalized-text type that could perhaps (depending on
locale) take advantage of simpler, more-efficient comparison
functions?
That might be nice, but I'd be wary
On Sep 24, 2009, at 8:59 AM, Andrew Dunstan wrote:
That might be nice, but I'd be wary of a geometric multiplication
of text types. We already have TEXT and CITEXT; what if we had your
NTEXT (normalized text) but I wanted it to also be case-insensitive?
Actually, I don't think it's
On Sep 23, 2009, at 5:27 PM, Andrew Gierth wrote:
I intentionally avoided hstore_to_array because it would be unclear
which one it meant (the 1-d or 2-d result).
Thanks Andrew.
Given these replies, unless anyone else wants to weigh in on the array
conversion operator and function names,
On Sep 26, 2009, at 12:33 PM, Josh Berkus wrote:
There's always pgtap. Whenever we find a new corner case, we add it
to
the development test suite.
Also, for C TAP, there's [libtap](http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap
). You can then use `prove` which you likely already
On Sep 29, 2009, at 8:55 AM, Richard Huxton wrote:
For the browser, does the following match what you're after, Andrew?
- clicking chapter title opens the browser panel
- panel stays open until you click close icon
- panel contains collapsable tree of chapter/section headings
Alternatively,
On Sep 29, 2009, at 4:11 PM, Andrew Gierth wrote:
I don't feel particularly strongly about the name (I've also
intentionally held off on updating the pgfoundry version of the code
until this is settled so no-one else should care either).
I'm down with hstore_to_array() and hstore_to_matrix().
On Sep 29, 2009, at 5:00 PM, Andrew Gierth wrote:
David Sure. But I realized that I forgot to ask for
David array_to_hstore() and matrix_to_hstore(). :-) Would love to
David have those, too. Not sure about the operators…
hstore(text[]) (which is also present as an explicit cast) covers both
of
On Sep 30, 2009, at 12:52 PM, Tom Lane wrote:
Applied with some mostly-cosmetic editorialization.
And there was much rejoicing…
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Oct 1, 2009, at 1:12 AM, Richard Huxton wrote:
Why wouldn't the entire TOC be in a collapsed list?
Permanently on-screen? My only concern there would be for people
viewing
on phones etc.
I have to admit that I'm never looking at the Pg docs on my iPhone.
This is mainly because I use
On Oct 1, 2009, at 3:42 PM, Tom Lane wrote:
My inclination is to think that the right behavior for REPLACE
FUNCTION
is to keep the old proowner and proacl values, because that's what it
always has done and nobody's complained. But I suppose a case could
be made that you're completely
On Oct 2, 2009, at 7:49 AM, Tom Lane wrote:
But in fact CREATE OR REPLACE is *not* meant to be the same as DROP
followed by CREATE. What it is meant to do is allow you to replace
the
implementation of the function while existing callers see it as still
being the same function. Thus we
On Oct 2, 2009, at 8:20 AM, Bruce Momjian wrote:
Most modules just install functions, which are easily
uninstalled/reinstalled. A data type like hstore is more complicated
assuming it is the data type that is changing and not the support
functions.
Lots of modules install data types. From
On Oct 2, 2009, at 8:49 AM, Tom Lane wrote:
The ideal is that backends will start using the new function
implementation on the next call after the REPLACE commits (but any
evaluations already in progress must of course continue with the text
they have). We have been gradually getting closer to
On Oct 2, 2009, at 9:43 AM, Alvaro Herrera wrote:
Plus lots of stuff on pgFoundry. It's a problem that needs to be
solved. Surely someone, somewhere, has solved this problem, no?
Dump reload?
Hahahahaha. No, really. Dump reload is a phrase that end users
will not put up with for much
On Oct 2, 2009, at 10:04 AM, Alvaro Herrera wrote:
The point is it's *not* solved in the context of using pg_migrator.
Yes, that's my point too, against David's argument that surely
someone
must have solved it. What we have here is a new problem, so it's not
so clear that there's any
On Oct 2, 2009, at 11:14 AM, Bruce Momjian wrote:
Well, if it is just changed syntax, we could wack around the system
catalogs. If storage changes, we have to dump/reload that data type.
Andrew solved this problem for hstore by making the new version able
to read the old representation. It
On Oct 4, 2009, at 1:57 PM, David Fetter wrote:
It's less about like or dislike and more about facing up to the
reality that we've got a major legacy foot-gun left over from the
experimentation of the Berkeley days.
I think you're going to need to be a bit more concrete than that. In
what
On Oct 7, 2009, at 7:55 AM, Andrew Dunstan wrote:
BTW I've seen requests for PL/Js so I'm sure it'll be welcome. What
license is v8 under?
It's a BSD license, but it's a C++ API. While it looks cool, I think
SpiderMonkey is possibly a better bet.
SquirrelFish?
On Oct 7, 2009, at 9:53 AM, David Fetter wrote:
At the moment, we have no way to test this, although with certain Perl
modules, it would be pretty trivial.
No non-core modules necessary. Just use Test::More and file handles
opened via pipes to two or more psql sessions.
Best,
David
--
On Oct 7, 2009, at 10:38 AM, David Fetter wrote:
When did Test::More become core? I believe we support back to Perl
5.6 :/
Module::CoreList says 5.006002, though I would have sworn it was added
much earlier than that. You could always use Test.pm, I suppose, which
has been in core since
On Oct 7, 2009, at 5:18 PM, Jeff Janes wrote:
I'd much rather live without Test::More and use DBD::Pg, then have
Test::More but need to open pipes to psql to talk to the database,
rather than using DBI to do it. But I guess we would need to worry
about whether we can make DBD::Pg work with the
On Oct 7, 2009, at 9:00 PM, Steve Prentice wrote:
Committed with a fair amount of corner-case cleanup and refactoring.
Woot! Thanks for all the hard work getting this committed (Pavel,
Bernd, Jeff, Tom and others)! I've been really looking forward to
this feature. Still hoping a solution
On Oct 8, 2009, at 9:47 AM, Jeff Davis wrote:
It's just the call notation -- the function only needs to know what
arguments it got for which parameters.
So they're still ordered? I'm thinking of PL/Perl here…
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Oct 10, 2009, at 7:55 PM, Robert Haas wrote:
After some thought and reflection, I'm inclined to suggest that on
10/15 we move all the remaining patches to the next CommitFest,
declare this one closed, and stamp alpha2 on schedule.
+1, FWIW.
David
--
Sent via pgsql-hackers mailing list
On Oct 19, 2009, at 7:54 AM, Stephen Frost wrote:
4. Resolve ambiguous names as query column, but throw warning
#4 would be my vote, followed by #3. To be perfectly honest, I'd be a
whole lot happier with a pl/pgsql that let me prefix variable names
with
a '$' or similar to get away from
On Oct 19, 2009, at 8:36 AM, Robert Haas wrote:
I think warnings are too easy to miss, but I agree your other
suggestion. I know you can write function_name.variable_name, but
that's often massively long-winded. We either need a short, fixed
prefix, or some kind of sigil. I previously
On Oct 19, 2009, at 9:29 AM, Stephen Frost wrote:
Uh, what dollar quoting? $_$ is what I typically use, so I wouldn't
expect a $ prefix to cause a problem. I think it'd be more of an
issue
because pl/pgsql still uses $1 and whatnot internally (doesn't it?).
Yes, but that's no more an
On Oct 19, 2009, at 9:49 AM, Tom Lane wrote:
I'd sure love $, as it's like shell, Perl, and other stuff.
This discussion has gotten utterly off track. The problem I am trying
to solve is a non-Oracle-compatible behavior in plpgsql. I have got
substantially less than zero interest in
On Oct 19, 2009, at 11:47 AM, Tom Lane wrote:
1. Invent a GUC that has the settings backwards-compatible,
oracle-compatible, throw-error (exact spellings TBD). Factory
default,
at least for a few releases, will be throw-error. Make it SUSET so
that
unprivileged users can't break things
On Oct 19, 2009, at 12:05 PM, Tom Lane wrote:
What about adopting the modifier syntax you're adding to COPY?
Where exactly would you put the modifier, and why is that better than
the existing #option convention?
CREATE OR REPLACE FUNCTION foo()
RETURNS BOOLEAN
LANGUAGE plpgsql WITH opt1,
On Oct 19, 2009, at 12:23 PM, Tom Lane wrote:
That is, the specification of options is made outside of the language
in question.
I don't think I particularly care for this. It's inventing a global
mechanism to cover a problem that we currently have one instance of
in one PL. That's a mighty
On Oct 21, 2009, at 7:27 AM, Tom Lane wrote:
Huh, it looks to me like that's an error in the declaration of the
citext versions of regexp_matches --- they should be declared to
return
setof text[], the same as the underlying text functions. David, do
you
agree?
Ooh, yeah, dunno how I
On Oct 21, 2009, at 9:37 AM, Tom Lane wrote:
Ooh, yeah, dunno how I missed that.
I think we're probably stuck in 8.4, but we should fix it going
forward. Would you make a quick check if any of the other citext
functions have the same bug?
I've fixed it in my [version for
On Oct 21, 2009, at 9:40 AM, David E. Wheeler wrote:
On Oct 21, 2009, at 9:37 AM, Tom Lane wrote:
Ooh, yeah, dunno how I missed that.
I think we're probably stuck in 8.4, but we should fix it going
forward. Would you make a quick check if any of the other citext
functions have the same bug
On Oct 21, 2009, at 9:48 AM, Tom Lane wrote:
I was wondering whether you could query pg_proc to look for functions
with the same name and different arguments/results. It's a bit tricky
though because you'd expect s/citext/text/ in at least some positions
(maybe not all)?
Yeah, almost all.
On Oct 21, 2009, at 11:37 AM, Robert Haas wrote:
That's like saying that it's less of a risk than a group of rabid
tyrannosaurs in a kindergarten classroom.
I'm not sure, but I kind of doubt that tyrannosaurs can get rabies. I
mean, if they were even around anymore. Which, you know, they're
On Oct 24, 2009, at 10:44 AM, Peter Eisentraut wrote:
More detail is available in the Release Notes included with each
alpha:
http://developer.postgresql.org/pgdocs/postgres/release-8.5.html
That seems to just have alpha1 at the moment.
Best,
David
--
Sent via pgsql-hackers mailing list
Howdy,
Very excited about the new `DO` command in 8.5a2. I read through the
patch review thread and found that, like me, Dim had expected it to
behave more like a lambda than a simple command. And from Tom's
comments, it looks like it was committed in such a way to make such
extensions
Howdy,
Very excited about the new `DO` command in 8.5a2. I read through the
patch review thread and found that, like me, Dim had expected it to
behave more like a lambda than a simple command. And from Tom's
comments, it looks like it was committed in such a way to make such
extensions
On Oct 26, 2009, at 1:16 PM, Pavel Stehule wrote:
I have a idea about migration of outer (psql) variables, and custom
shell variables.
some like:
psql --allow_custom_variables --table_name=mytable
inside psql we should to use :table_name variable with mytable as
content.
then we can use
On Oct 26, 2009, at 1:21 PM, Tom Lane wrote:
A lambda facility would require being able to pass arguments and
return
results, which we intentionally left out of DO to keep it simple. By
the time you add all that notation, it's far from clear that you
shouldn't just define a function.
Well
On Oct 26, 2009, at 2:12 PM, Pavel Stehule wrote:
it should be light relation. 'DO' should be parametrised, and psql can
use own variables as 'DO' parameters.
I see, because `DO` is a statement, not an expression. Thus arguments
don't really make much sense (I wish it was an expression!).
On Nov 3, 2009, at 10:32 AM, Josh Berkus wrote:
So I'm going to make a case in favor of EOL'ing 7.4. In fact, I'd
be in
favor of doing so in, say, February after an announcement this month
+1
And, frankly, I think that we still need a published deprecation
policy -- or at least a set of
On Nov 4, 2009, at 5:34 PM, Tom Lane wrote:
According to
http://developer.postgresql.org/pgdocs/postgres/plpgsql-declarations.html#PLPGSQL-DECLARATION-RENAMING-VARS
the RENAME declaration in plpgsql has been known broken since PG 7.3.
Nobody has bothered to fix it. Shall we just rip it out?
On Nov 5, 2009, at 11:09 AM, Jeff Davis wrote:
I think EXCLUDING conflicts with the EXCLUDING in LIKE. Also, it
becomes
a little more difficult to place the access method clause, because
EXCLUDING USING gist doesn't sound great.
Well that's clearly a verb. So perhaps EXCLUDE USING
gist
On Nov 7, 2009, at 11:08 AM, Tom Lane wrote:
EXCLUDE probably flows most nicely with the optional USING clause or
without. My only complaint was that it's a transitive verb, so it
seems
to impart more meaning than it actually can. I doubt anyone would
actually be more confused in practice,
On Nov 8, 2009, at 7:43 PM, Jeff Davis wrote:
Either of those names are fine with me, too. The current name is a
somewhat shortened version of the name operator-based exclusion
constraints, so we can also just use that name. Or, just exclusion
constraints.
(exclusion constraints)++
David
--
On Nov 12, 2009, at 10:46 AM, David Fetter wrote:
My question boils down to, why is this string concatenation different
from all other string concatenations?
Does it have something to do with afikoman?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Nov 13, 2009, at 8:39 PM, Robert Haas wrote:
alter table foo add constraint bar exclude (a check with =, b check with =);
I've been meaning to comment on this syntax one more time; apologies for the
bike-shedding. But I'm wondering if the CHECK is strictly necessary there,
since the WITH
On Nov 14, 2009, at 8:55 AM, Tom Lane wrote:
I've been meaning to comment on this syntax one more time; apologies for the
bike-shedding. But I'm wondering if the CHECK is strictly necessary there,
since the WITH seems adequate, and there was some discussion before about
the CHECK keyword
Howdy,
I just saw this in the docs:
Finally, NATURAL is a shorthand form of USING: it forms a USING list
consisting of exactly those column names that appear in both input
tables. As with USING, these columns appear only once in the output
table.
That sounds useful if I happen to have
Howdy,
I just saw this in the docs:
Finally, NATURAL is a shorthand form of USING: it forms a USING list
consisting of exactly those column names that appear in both input
tables. As with USING, these columns appear only once in the output
table.
That sounds useful if I happen to have
On May 31, 2008, at 09:23, Tom Lane wrote:
1. Most people have no idea how to set these.
2. The current postgresql.conf file is a huge mess of 194 options,
the
vast majority of which most users will never touch.
3. GUCS lists are kept in 3 different places (guc.c, postgresql.conf,
and the
On May 31, 2008, at 12:36, Gregory Stark wrote:
What this sounds like is a sly way to try to get rid of
postgresql.conf
entirely and replace it with parameters stored in the database so
admins would
adjust the parameters using an SQL syntax rather than a text file.
There are pros and cons
On May 31, 2008, at 15:32, Peter Eisentraut wrote:
1. Most people have no idea how to set these.
Could you clarify this? I can't really believe that people are
incapable of
editing a configuration file.
I've been using PostgreSQL on and off, mostly on, for almost 10 years.
I still
Howdy,
I'm sure I'm just showing off my ignorance here, but here goes…
I really need case-insensitive string comparison in my database.
Ideally there'd be a nice ITEXT data type (and friends, ichar,
ivarchar, etc.). But of course there isn't, and for years I've just
used LOWER() on
On Jun 1, 2008, at 21:08, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
I really need case-insensitive string comparison in my database.
Okay ... according to whose locale?
I'm using C. Of course you're correct that it depends on the locale, I
always forget that. But does
On Jun 1, 2008, at 22:18, Tom Lane wrote:
I'm using C. Of course you're correct that it depends on the
locale, I
always forget that. But does not the Unicode standard offer up some
sort locale-independent case-insensitivity, so that it gets it right
some large percentage of the time?
Not
On Jun 1, 2008, at 22:21, Oleg Bartunov wrote:
David,
we wrote contrib module (mchar) for one customer, which ports its
application from mssql to postgres. It does case-insensitive
comparison for new data type 'mchar' and linked with ICU for system
independent locale.
That sounds
On Jun 2, 2008, at 06:51, Andrew Sullivan wrote:
On Sun, Jun 01, 2008 at 10:13:07PM -0700, David E. Wheeler wrote:
What locale is right? If I have a Web app, there could be data in
many
different languages in a single table/column.
I think the above amounts to a need for per-session
On Jun 1, 2008, at 21:08, Tom Lane wrote:
1. Does the use of the tolower() C function in the citext data type
on
pgfoundry basically give me the same results as using lower() in my
SQL has for all these years?
[ broken record... ] Kinda depends on your locale. However,
tolower()
is
On Jun 2, 2008, at 09:33, Tom Lane wrote:
Would the use of str_tolower() in formatting.c fix that?
Yeah, you need something equivalent to that. I think that whole area
is due for refactoring, though --- we've got kind of a weird
collection
of upper/lower/initcap APIs spread through a
On Jun 3, 2008, at 02:27, Zdenek Kotala wrote:
The proposal of GSoc is there:
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00857.php
It should create basic framework for full SQL COLLATION support. All
comments are welcome.
That looks great, Zdenek. I'm very excited to have
On Jun 3, 2008, at 12:06, Zdenek Kotala wrote:
It is simple. SQL standard does not specify notation for that
(chapter 11.34). But there is proposed notation:
CREATE COLLATION collation name FOR character set specification
FROM existing collation name [ pad characteristic ] [ case
On Jun 3, 2008, at 20:48, Greg Smith wrote:
Correct, but completely off-topic regardless. One problem to be
solved here is to take PostgreSQL tuning from zero to, say, 50%
automatic. Wander the user lists for a few months; the number of
completely misconfigured systems out there is
On Jun 4, 2008, at 07:19, Andreas Pflug wrote:
IMHO the best compromise in machine and human readability is an XML
format. It's easily decorateable with comments, easily interpreted
and a pg_settings view could enhance it with even more comments, so
an editor using pgsql functions (to read
On Jun 4, 2008, at 11:22, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
Exactly. The issue is that application developers, who are not DBAs,
have no idea how to tune PostgreSQL, and postgresql.conf is daunting
and confusing. So they use a different database that's faster.
I take
On Jun 4, 2008, at 12:48, Andrew Dunstan wrote:
I'm not much into MySQL, but in the work I've done with it, I've
had to create /etc/my.cnf myself. There *is* no configuration file
configuring MySQL until that file is created, is there? So there is
no configuration to learn at first. I'm
On Jun 4, 2008, at 13:31, Pavel Stehule wrote:
do you thing, so any better config can help? It's not possible. And
you can't tune database without well knowledge of applications that
use database. Any automatic tools are joy for child. But some default
PostgreSQL parameters are not optimal.
On Jun 4, 2008, at 13:12, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
I'm not much into MySQL, but in the work I've done with it, I've had
to create /etc/my.cnf myself. There *is* no configuration file
configuring MySQL until that file is created, is there? So
On Jun 4, 2008, at 13:57, Tom Lane wrote:
So I think we should stop worrying about the file format and think
about
these two problems:
* Can we present the config options in a more helpful way (this is 99%
a documentation problem, not a code problem)?
* Can we build a configuration wizard
Howdy,
I'm working on a custom data type based on TEXT that does case-
insensitive, locale-aware comparisons, essentially by calling LOWER()
to compare values. I'll have more to ask about this later, when I want
to get feedback on the implementation. But right now I'm just writing
tests
On Jun 5, 2008, at 11:28, Martijn van Oosterhout wrote:
On Thu, Jun 05, 2008 at 11:18:26AM -0700, David E. Wheeler wrote:
I'm working on a custom data type based on TEXT that does case-
insensitive, locale-aware comparisons, essentially by calling LOWER()
to compare values.
What makes
On Jun 5, 2008, at 11:51, Tom Lane wrote:
I was thinking that the ::text should be cast to ::lctext, as that's
how `'a'::lctext = 'a'` works, but I keep going back and forth in my
mind. Maybe 'a'::lctext should not equal 'A'::text.
It seems to me that lctext is sort of like a more-constrained
On Jun 5, 2008, at 14:07, Martijn van Oosterhout wrote:
I'm sure I'm missing something simple here. How do I make it
assignment?
# \h create cast
Command: CREATE CAST
Description: define a new cast
Syntax:
snip
CREATE CAST (sourcetype AS targettype)
WITHOUT FUNCTION
[ AS ASSIGNMENT
On Jun 5, 2008, at 14:47, Greg Smith wrote:
This is why there's the emphasis on preserving comments as they pass
into the GUC structure and back to an output file. This is one of
the implementation details I haven't fully made up my mind on: how
to clearly label user comments in the
On Jun 5, 2008, at 17:53, Greg Smith wrote:
I was already considering keeping user comments as # while making
all system-inserted ones #! ; many people are already used to #!
having a special system-related meaning from its use in UNIX shell
scripting which makes it easier to remember.
On Jun 5, 2008, at 23:08, Heikki Linnakangas wrote:
What comments do we consider machine-generated? Just the ones used
to comment out settings, like
#shared_buffers = 32MB
or something else?
Those and documentation comments.
If the automatic tool lets alone all other kind of comments, I
On Jun 6, 2008, at 01:50, Andreas Pflug wrote:
Two heretical questions:
Do we need user generated comments at all?
I can't remember ever having used any comment in postgresql.conf.
That's a valid point. I've used comments to note by whom and when when
a setting was changed.
Why do so many
On Jun 12, 2008, at 17:55, Greg Sabino Mullane wrote:
Glad to hear that, although I think this is only in HEAD, not
backpatched,
right? Well at any rate, I withdraw my strong support for 100 and
join in
the quest for a good number. The anything but 10 campaign
I vote for 11. That's one
Howdy,
Possibly showing my ignorance here, but as I'm working on updating
citext to be locale-aware and to work on 8.3, I've run into this
peculiarity:
try=# \encoding
UTF8
try=# select setting from pg_settings where name = 'lc_collate';
setting
-
en_US.UTF-8
(1 row)
try=#
On Jun 16, 2008, at 02:52, Martijn van Oosterhout wrote:
The only odd thing I see is the use of PG_ARGS to pass the arguments
to
citextcmp. But I can't see why it would break either. Can you attach a
debugger and see where it goes wrong?
Yes, I can do that, although I'm pretty new to C (let
On Jun 16, 2008, at 09:24, David E. Wheeler wrote:
On Jun 16, 2008, at 02:52, Martijn van Oosterhout wrote:
The only odd thing I see is the use of PG_ARGS to pass the
arguments to
citextcmp. But I can't see why it would break either. Can you
attach a
debugger and see where it goes wrong
On Jun 16, 2008, at 13:06, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
What's even weirder is that it can not work and then suddenly work:
Smells like uninitialized-memory problems to me. Perhaps you are
miscalculating the length of the input data?
Entirely possible. Here
On Jun 16, 2008, at 13:41, Martijn van Oosterhout wrote:
Actually, real dumb question but: arn't you assume that text* values
are NULL terminated, because they're not...
char * cilower(text * arg) {
// Do I need to free anything here?
char * str = VARDATA_ANY( arg );
str here is not
On Jun 16, 2008, at 14:38, Tom Lane wrote:
It's complaining about the use in ORDER BY.
Okay, so stupid question: How can I get an array of the values in a
given order? I guess this works:
select array_accum(b) from ( select name from srt order by name ) AS
A(b);
Thanks,
David
--
On Jun 16, 2008, at 16:48, David Fetter wrote:
select array_accum(b) from ( select name from srt order by name ) AS
A(b);
SELECT ARRAY(SELECT name FROM srt ORDER BY name); -- also works.
Wow, somehow I'd missed that syntax over the years. Thanks David!
Best,
David
--
Sent via
301 - 400 of 1565 matches
Mail list logo
