On Jun 23, 2009, at 3:02 PM, Dimitri Fontaine wrote:
If we happen to accept the debian policy versioning scheme, then the
hard work is already done for us, it seems:
http://packages.debian.org/fr/sid/postgresql-8.3-debversion
As long as we don't need to implement a new data type, fine.
Howdy,
I was just looking at the documentation for cursors command, and
noticed that the MOVE command's direction argument doesn't seem to
have documentation for its possible values.
http://www.postgresql.org/docs/8.4/static/sql-move.html
I assume that they should be FORWARD and
On Jun 21, 2009, at 5:07 PM, David E. Wheeler wrote:
I was just looking at the documentation for cursors command, and
noticed that the MOVE command's direction argument doesn't seem to
have documentation for its possible values.
http://www.postgresql.org/docs/8.4/static/sql-move.html
I
On Jun 17, 2009, at 8:08 AM, Tom Lane wrote:
Pavel Golub pa...@microolap.com writes:
Is there any possibility that Postgres will have named transaction
ever, like Firebird?
What in heck is a named transaction, and why should we care?
That Tom Lane, so warm and cuddly!
David
--
Sent via
On Jun 10, 2009, at 11:06 PM, KaiGai Kohei wrote:
The SE-PostgreSQL patches are updated as follows:
Kohei-San,
I've no idea whether SE-PostgreSQL will ever make it into the core
distribution, and have no way to really determine whether or not it's
a good idea, but I did want to say:
I
On Jun 4, 2009, at 3:58 PM, Tom Lane wrote:
It seems we have two reasonable possibilities for 8.4: revert that
patch
and keep contrib/intarray's behavior the same as it was, or leave the
patch in and document that there was a behavioral change.
You can't keep the patch and update intarray
On Jun 2, 2009, at 8:43 AM, Tom Lane wrote:
Each of these is configured (using --prefix) to install into a
separate
installation tree. So I can switch my attention to one branch or
another by cd'ing to the right place and adjusting a few environment
variables such as PATH and PGDATA.
Yeah,
On Jun 2, 2009, at 9:03 AM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
Yeah, with git, rather than cd'ing to another directory, you'd just
do
`git checkout rel8_3` and work from the same directory.
That's what I'd gathered, and frankly it is not an acceptable answer
On Jun 2, 2009, at 9:16 AM, Alvaro Herrera wrote:
Well, you can have as many clones of a repository as you like. You
can
keep one with master checked out, another with rel8_3, another with
rel8_2, etc. You'd just have to write a script to keep them in sync
(shouldn't be too difficult, each
On Jun 2, 2009, at 9:23 AM, Aidan Van Dyk wrote:
Yeah, with git, rather than cd'ing to another directory, you'd just
do
`git checkout rel8_3` and work from the same directory.
But that looses his configured and compiled state...
But git isn't forcing him to change his workflow at all...
On Jun 2, 2009, at 2:31 PM, Tom Lane wrote:
It's a bit premature to speculate about alternate history tools when
we haven't figured out what the repository is going to look like.
Right
at the moment I'm much more concerned about the question of supporting
a checkout-per-branch workflow.
On Jun 2, 2009, at 3:11 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
Perhaps there's a master repository that corresonds to CVS HEAD, and
then release branches are actually separate git repositories.
Yeah, I was speculating about that one too. It might be workable.
Just
On Jun 2, 2009, at 3:33 PM, Tom Lane wrote:
A back-branch-only fix would look the same except for not having any
unannotated filenames. I'm too lazy to go trolling for one just now.
God Tom, you're such a bloody slacker. Sheesh!
It's also possible to get it to produce histories that
On Jun 2, 2009, at 3:56 PM, Tom Lane wrote:
Well, it's not like CVS makes it easy ... cvs2cl is about 50K of perl,
and is not very speedy or without bugs :-(. So maybe we are setting
the goalposts in the wrong place by supposing that the lowest-level
git
history needs to be exactly what's
On Jun 2, 2009, at 3:55 PM, Andrew Dunstan wrote:
Umm, no. there are *no* ,v files in my working copies (I just
checked, to make sure I wasn't on crack). The repository has them,
but the working copy does not. SVN does keep the equivalent - that's
how you can work offline for doing things
On Jun 2, 2009, at 4:13 PM, Tom Lane wrote:
I think you missed the part of the discussion about not wishing to
share
a single working directory across all the branches.
No, I was just ignoring it for the moment to focus on the commit and
history issue.
The time to rebuild
derived files
On Jun 2, 2009, at 4:39 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
Does that make sense?
Maybe, but it still seems messy, brute force, and error-prone.
I can't escape the feeling that we're missing something basic here.
It's allegedly one of git's great strengths
On Jun 2, 2009, at 5:26 PM, Josh Berkus wrote:
Tom, all,
More suggested dispositions:
* plperl fails with Perl 5.10 on Windows
o tgl says: no reports of this with pre-8.4 Postgres, but I
bet that's just because no one tried it
o dpage says: I'm rolling back the Windows
On May 31, 2009, at 3:47 PM, Greg Stark wrote:
On Sun, May 31, 2009 at 9:12 PM, Josh Berkus j...@agliodbs.com
wrote:
This assumes that all users should have access to the same public
APIs as
all other users. Real applications are more complex.
Well the goal is to make them simpler. I
On May 29, 2009, at 5:16 PM, Greg Stark wrote:
On Fri, May 29, 2009 at 11:03 PM, David E. Wheeler da...@kineticode.com
wrote:
On May 29, 2009, at 2:52 PM, Josh Berkus wrote:
a) the ability to push a schema onto the current search path
b) the ability to pull a schema off the current search
On May 29, 2009, at 4:59 AM, Kevin Field wrote:
http://github.com/theory/pgtap/tree/master/
I'm getting a new version ready to release as I type.
Thanks, great to know. :) Although, I do think changing plperl is
the more proper option, so I'm going to try there first...
I added
On May 29, 2009, at 3:24 AM, Peter Eisentraut wrote:
Yeah, to reiterate what I posted elsewhere, perhaps it'd be a good
idea to
give up on the search path idea altogether and think more in terms
of an
import facility like Python, Java, and sometimes Perl have.
+1
Actually, Perl's is
On May 29, 2009, at 3:38 AM, Dimitri Fontaine wrote:
PS: we still have to provide users with easy tools to (dynamically)
manage search_path, don't we?
(I prefer not to start the search_path management tool ideas right
here).
Yes, we do, and that's what at least half this thread is about.
On May 29, 2009, at 12:41 PM, Greg Stark wrote:
That said, I don't mind the idea of having a way to push things onto
search path like you often do in sh using PATH=/foo/bar:$PATH.
Yes, +1.
But I think the only reason to install something into a separate
schema is precisely if you *want*
On May 29, 2009, at 2:45 PM, Greg Stark wrote:
2) Normally programming languages do early binding so as soon as the
code is parsed references are resolved. You can't later define a new
function earlier in the search path and have it take over references
that have were previously referring to
On May 29, 2009, at 2:52 PM, Josh Berkus wrote:
a) the ability to push a schema onto the current search path
b) the ability to pull a schema off the current search path
push, pop, shift, unshift. :-)
Come to think of it, I want these for arrays, too. ;-)
Best,
David
--
Sent via
On May 28, 2009, at 1:34 AM, Dimitri Fontaine wrote:
Andrew Dunstan and...@dunslane.net writes:
Dimitri Fontaine wrote:
we all agree that a specific pg_extension schema is a good idea,
as
soon as user is free not to use it at extension install time.
I don't think we all agree on that
On May 28, 2009, at 1:13 AM, Dimitri Fontaine wrote:
Having all extensions live in pg_extension schema also solves the
problem in a much easier way, except for people who care about not
messing it all within a single schema (fourre-tout is the french for a
place where you put anything and
On May 28, 2009, at 12:22 PM, Tom Lane wrote:
What you need is a test that looks at the SQLSTATE code, and little
if anything else.
Yes, and throws_ok() supports that:
SELECT throws_ok( 'SELECT 1 / 0', '22012' );
Best,
David
--
Sent via pgsql-hackers mailing list
On May 28, 2009, at 12:53 PM, Kevin Field wrote:
Can pgTap check for a regex instead if just a string?
That's the other option, if the pgTAP author is willing...if the
SQLSTATE thing doesn't work out I guess we'll have to go down that
road.
Patches welcome. ;-)
On May 28, 2009, at 11:27 AM, Greg Stark wrote:
On Thu, May 28, 2009 at 5:30 PM, David E. Wheeler da...@kineticode.com
wrote:
Yes, just as long as your extensions schema doesn't turn into a
bricolage of
stuff. I mean, if I use a lot of extensions, it means that I end up
with a
giant
On May 28, 2009, at 11:38 AM, Tom Lane wrote:
I suppose there might be some use-case involving concurrent
installation
of multiple versions of the *same* extension, but I'm not sure we
should
be designing around that as a key case.
Agreed. One thing at a time.
Best,
David
--
Sent via
On May 28, 2009, at 12:10 PM, Robert Haas wrote:
It feels like a Java CLASSPATH,
or installing every application into /usr/local/application-name so
that your path has 50 bin directories in it.
+1 Yeah, that was my trouble with it.
Best,
David
--
Sent via pgsql-hackers mailing list
On May 28, 2009, at 12:33 PM, Tom Lane wrote:
Greg Stark st...@enterprisedb.com writes:
Is that really a complete answer? How do we deal with upgrading an
extension to a more recent version? What happens to objects in the
database which depend on objects from the extension?
Well, if it's
On May 25, 2009, at 2:16 AM, Dimitri Fontaine wrote:
Proposal: pg_extension, a new dedicated system schema for extensions
Good:
It's easy to see SQL objects (\df) of extensions (think contribs) you
installed, and as extension developpers are required to use it, you
don't have to care about
On May 27, 2009, at 1:50 AM, Dimitri Fontaine wrote:
The moment you're adding specific schemas where to put extensions
into,
you have to adapt your search_path. Some applications already have to
manage search_path for their own needs, so we're trying to avoid
having
those people to care
On May 27, 2009, at 1:49 PM, Andrew Gierth wrote:
Splitting up search_path is something I've been thinking about for a
while (and threw out on IRC as a suggestion, which is where Dimitri
got it); it was based on actual experience running an app that set the
search path in the connection
On May 27, 2009, at 2:14 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Another way of handling this might be to provide for prepending or
appending to the search path (or even for removing items from it).
I was just about to raise that as a requirement.
Yeah, I likes.
On May 8, 2009, at 4:00 PM, Peter Eisentraut wrote:
(You can't be serious that for reverting a WC file to the repository
state you use git checkout?)
Why not? The purpose of the operation is to get a file from the
repository.
It's not much different whether you do it the first or the
On May 7, 2009, at 10:18 AM, Tom Lane wrote:
Actually, there's another issue that comes to mind here: since we are
relying on platform-dependent locale names, including those in the
dump
is going to pose a severe problem for porting dumps across platforms
(where different platform could even
On May 7, 2009, at 12:32 PM, Tom Lane wrote:
Or we could try to make the user-visible locale names
platform-independent in the first place, a la David's not-silly-at-all
suggestion.
Actually, what I was thinking of was using a platform-independent
locale infrastructure: the inconsistency in
On May 1, 2009, at 10:38 AM, Andrew Dunstan wrote:
Please, let's not have a whole host of different indentation styles.
Postgres has a well established style. Let's stick to it in both
perl and C
+1
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On May 1, 2009, at 8:38 AM, Robert Haas wrote:
Speaking of space/tab settings, one thing I'm fuzzy on is the rule for
wrapping long lines. I understand that a line that extends past 80
characters has to be wrapped, but the amount of indentation on the
continuation line doesn't appear to follow
On May 1, 2009, at 10:54 AM, David Fetter wrote:
foreach my $element (@array) {
# clear, short, idiomatic code here
}
instead of Rube Goldberg constructs like this:
my $i;
for ($i=0; $i = $#array; ++$i)
{
# kludges up down and sideways here
}
is a good idea because it makes it easier
On Apr 23, 2009, at 12:22 AM, Heikki Linnakangas wrote:
Zdenek Kotala wrote:
It seems to me that citex_cmp can return any integer value. It
depends
what wcscoll() returns. I think it should be changed to:
SELECT citext_cmp('B'::citext, 'a'::citext) 0 AS one;
The comment in varstr_cmp()
On Apr 23, 2009, at 12:00 PM, Tom Lane wrote:
You can get around this by cloning template0 instead of template1
(we assume template0 contains nothing that's encoding-specific).
Possibly the docs will need to be improved to emphasize that.
I was just about to suggest that. With this change,
On Apr 15, 2009, at 4:45 AM, Sam Mason wrote:
Doh, yes it does doesn't it. Sorry I searched for a bit and failed to
find anything before. Looks as though the signal to noise ratio was
far
too low as I've just searched again and found a (single) reference to
their docs describing the
On Apr 14, 2009, at 9:26 AM, Tom Lane wrote:
Another question is what is the purpose of a database? To me it
would
be quite the wrong thing for the DB to not store what is presented, as
long as it's considered legal. Normalization of legal variant forms
seems pretty questionable. So I'm
On Apr 14, 2009, at 11:22 AM, Tom Lane wrote:
BTW, does anyone know whether Unicode includes the ASCII control
characters ... ie, is \u0009 a name for tab? If so, maybe this
syntax is in part an attempt to cover that use-case in the standard.
Yes, you can use, e.g., #x0009; in HTML to
On Apr 14, 2009, at 11:10 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I think there's a good case for some functions implementing the
various
Unicode normalization functions, though.
I have no objection to that so long as the code footprint is in line
with the utility
On Apr 10, 2009, at 12:15 PM, Tom Lane wrote:
I gave my reasoning before: widening this API has possibly nontrivial
future maintenance costs, and the actual use-case for the data is
unconvincing.
It seems to me that the immediate patch to simply copy zone.tab has no
effect on the API.
On Apr 7, 2009, at 8:07 AM, Steve Crawford wrote:
In scenario 2, there were two options:
2a. Return zero-element array.
2b. Return array with single empty-string element.
My impression was that among the change options, 2b had the most
support (it is the most useful for the use-cases I've
On Apr 7, 2009, at 3:26 PM, Alvaro Herrera wrote:
Agreed, it seems to me that a patch to install zone.tab during make
install could be applied at this time (before beta so that packagers
don't complain that we didn't give them time to fix their file lists).
A more complete patch can be
On Apr 6, 2009, at 5:48 PM, Tom Lane wrote:
Andrew Gierth and...@tao11.riddles.org.uk writes:
At the VERY LEAST, can we PLEASE have the zone.tab file
INSTALLED WHERE IT BELONGS rather than simply ignored, so that even
if
further requests to include the information in a system view go
On Apr 2, 2009, at 7:20 AM, Steven Lembark wrote:
Note that since the Internships are not required to be project code,
we can also take student projects to contribute to our WWW
infrastructure and other areas the project needs some work.
Would introducing a Duration (i.e., time-series
a'la
On Apr 1, 2009, at 12:19 PM, Robert Haas wrote:
my @ints = map { $_ || 0 } split ',', $string;
This ensures that I get the proper number of records in the example
of something like '1,2,,4'.
I can't see that there's any way to do this in SQL regardless of how
we define this operation.
On Apr 1, 2009, at 2:22 PM, Tom Lane wrote:
Another way to state the point is that we can offer people a choice of
two limitations: string_to_array doesn't work for zero-length lists,
or string_to_array doesn't work for empty strings (except most of the
time, it does). The former is sounding
On Apr 2, 2009, at 11:24 AM, Sam Mason wrote:
Yes, I'd be tempted to pick one and go with it. It's seems a
completely
arbitrary choice one way or the other but the current behaviour is
certainly wrong.
I'd go with returning a zero element array because it would do
the right thing more often
On Apr 1, 2009, at 9:02 AM, Tom Lane wrote:
+1. I find this argument much more compelling than anything else
that's been offered up so far.
Yeah. It seems to me that if you consider only the case where the
array
elements are text, there's a weak preference for considering '' to
be a
On Apr 1, 2009, at 10:09 AM, Tom Lane wrote:
Thus, this is not a problem with string_to_array(), but a
casting problem from text[] to int[].
Nonsense. The question is whether string_to_array is meant to be
useful
for lists of anything except text. I agree you could argue that it
isn't.
On Apr 1, 2009, at 10:05 AM, justin wrote:
string_to_array('',',')::INT[] works as proposed
But
string_to_array(',,,', ',' )::INT[] Fails
or
string_to_array('1,2,,4', ',' )::INT[] Fails .
I'm trying to understand the difference between a empty string to a
string with many blank entries
On Mar 31, 2009, at 8:34 AM, Sam Mason wrote:
What do you really expect to be returned for things like
select count_elements(string_to_array('butter,tea,milk',','))
3 = {butter,tea,milk}
select count_elements(string_to_array('butter,tea',','))
2 = {butter,tea}
select
On Mar 30, 2009, at 8:26 PM, Tom Lane wrote:
Does anyone want to argue for keeping it the same? Or perhaps
argue that a zero-element array is a more sensible result than
a one-element array with one empty string? (It doesn't seem
like it to me, but maybe somebody thinks so.)
Hrm. There
On Mar 29, 2009, at 10:08 PM, Josh Berkus wrote:
Due to budget constraints, Google needed to cut 50 projects from the
Summer of Code this year. We were one of the projects cut (although
we
can re-apply next year).
Leslie at Google has asked me to clarify this. We *also* made a
mistake
On Mar 27, 2009, at 6:40 PM, Bruce Momjian wrote:
Thanks, text updated:
While semi-joins merely replace existing IN joins, anti-joins
are a new capability for NOT EXISTS clauses (Tom) This improves
optimization possibilities.
I'm not enough of a relational algebra geek to
On Mar 25, 2009, at 2:39 PM, Josh Berkus wrote:
Note that since the Internships are not required to be project code,
we can also take student projects to contribute to our WWW
infrastructure and other areas the project needs some work.
God, could someone do the module thing? :-
I'd be
On Mar 24, 2009, at 9:41 AM, Bruce Momjian wrote:
So far taking the CVS logs and making a list of only the items we want
for the release notes took one day; researching and rewording the
items
so they are ready for the release notes took five days; grouping them
into sections and
On Mar 24, 2009, at 2:51 PM, Andrew Gierth wrote:
By popular demand, a version of this will go up on pgfoundry for use
with 8.3 etc.
Wow. Nice stuff! I hope it's not too late for 8.4…
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Mar 16, 2009, at 1:41 PM, Tom Lane wrote:
A saner policy would mandate that large patches land near the start of
a development cycle, but I don't know how we get people to do that.
I think that if you can strictly time-limit the final CommitFest in
the same way that you time-limit the
On Mar 13, 2009, at 11:06 AM, Andrew Gierth wrote:
If there's any other features that people find notably missing from
hstore, I could stick them in too; any requests?
Can you create slices? That is, create a new hstore as a subset of an
existing hstore?
Also, hstore has an
On Mar 13, 2009, at 1:21 PM, Andrew Gierth wrote:
I'm thinking that (hstore - text[]) should probably return
text[],
and maybe (hstore = text[]) returning hstore?
i.e.
select ('a=1,b=2,c=3'::hstore) - ARRAY['a','b'];
-- returns '{1,2}'
select ('a=1,b=2,c=3'::hstore) = ARRAY['a','b'];
--
On Mar 13, 2009, at 2:26 PM, Andrew Gierth wrote:
David Is a more Perlish syntax out of the question?
Yes. Sorry.
David SELECT ('a=1,b=2,c=3'::hstore)['a', 'b'];
David -- returns '{1,2}'
That would require integrating hstore into core - array subscripting
isn't a user-definable operation.
On Mar 13, 2009, at 2:35 PM, Tom Lane wrote:
Is a more Perlish syntax out of the question?
Yes. SQL is not Perl.
You mean all this time I thought I was writing Perl when I was using
PostgreSQL, and it turns out that it's *not* Perl? That explains the
strange lack of sigils.
Thanks
Howdy,
I was just updating a function in pgTAP that, given a schema name and
an array of function names, returns a set of those function names that
are not in the named schema. I got it working with a subquery, and
David Fetter suggested that I try an EXCEPT query instead. The only
On Feb 19, 2009, at 5:45 PM, Andrew Dunstan wrote:
A limitation of this feature is that an ORDER BY clause applying to
the result of a UNION, INTERSECT, or EXCEPT clause can only specify
an output column name or number, not an expression.
Why not just say order by 1 ?
Well, in this case,
On Feb 7, 2009, at 12:11 PM, Bruce Momjian wrote:
can we just apply this one and let this discussion off?
or maybe remove the OFFSET part and point to the SQL COMMAND
references page? (doesn't seem appropiate to me to reject the LIMIT
comment and let the other one in there while they are almost
On Feb 6, 2009, at 9:33 AM, Bruce Momjian wrote:
Oh, is the FAQ on the site built from CVS tip? Is there not a branch
for 8.3 from which it's built?
There are FAQ's in each branch, but the one that is put on the web
site
is from CVS HEAD.
Oh. That seems kind of odd…can you hang onto the
On Feb 6, 2009, at 9:12 AM, Bruce Momjian wrote:
Quick patch to mention CITEXT in the parts of the FAQ that discuss
case-insensitive comparisons.
I think it is too early to mention /contrib/citext in the FAQ because
8.4 is not released yet.
Oh, is the FAQ on the site built from CVS tip? Is
On Feb 6, 2009, at 9:12 AM, Bruce Momjian wrote:
Quick patch to mention CITEXT in the parts of the FAQ that discuss
case-insensitive comparisons.
I think it is too early to mention /contrib/citext in the FAQ because
8.4 is not released yet.
Oh, is the FAQ on the site built from CVS tip? Is
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 in 8.4
too.
Ah, yeah, I didn't put that in the patch…
On Feb 4, 2009, at 5:25 AM, Andrew Dunstan wrote:
In effect it does say that - perhaps not quite as explicitly as you
might have wanted. It says: The information in this part is
presented in a narrative fashion in topical units. Readers looking
for a complete description of a particular
On Feb 4, 2009, at 9:25 AM, Robert Haas wrote:
Oh, dear. If this turns out to be my bug Tom will kick my ass!
Can I buy tickets to this event?
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Feb 4, 2009, at 9:33 AM, Robert Haas wrote:
Just to play devil's advocate, I have used the PostgreSQL
documentation for years and have long understood that the references
pages are the place to go if you really need the nitty-gritty on how a
particular command works. I agree that you might
On Feb 4, 2009, at 10:04 AM, Svenne Krap wrote:
I have the same experience, I also go directly for the most technical
parts. But even I sometimes search and hit those narrative ones
Btw. there seems to be no section VI (i.e. non-narrative) page about
datatypes and functions... things there
On Feb 2, 2009, at 1:52 PM, Robert Haas wrote:
We don't really have space to document every little niggling
detail in
two places; if we did that, the main docs would become unreadably
dense.
What, disk space? What do you mean by space?
Brain space.
Heh. Okay. Well, should there be a
On Feb 3, 2009, at 8:40 AM, Andrew Dunstan wrote:
We have one page per main SQL verb (e.g. SELECT or CREATE TABLE). I
don't think we want to break it up more than that. One page for each
clause would be a nightmare to maintain.
Then should the LIMIT/OFFSET page go away?
Best,
David
--
On Feb 3, 2009, at 1:30 PM, Andrew Dunstan wrote:
I was referring to the reference section. I see you were referring
to the more descriptive but probably less complete Section II.
Yes.
I see Section II says at the beginning: Readers looking for a
complete description of a particular
On Feb 3, 2009, at 1:06 PM, Tom Lane wrote:
The reference documentation is *always* intended to be more complete
and
more authoritative than the narrative description. If you don't think
so then you need to readjust your expectations.
Yes, but I didn't even know I was looking at a brief
On Feb 2, 2009, at 9:58 AM, Bruce Momjian wrote:
Is it intentional that `LIMIT NULL` means the same as `LIMIT ALL`? If
so, I'd like to submit a patch to document it, because I've found it
useful in SQL functions:
http://justatheory.com/computers/databases/postgresql/dynamic-limit.html
Uh,
On Feb 2, 2009, at 10:17 AM, Tom Lane wrote:
It's worked the way it does now since 7.1, and no one has complained;
in fact we've gotten bug reports when it was broken by the int8-limit
patch. So there are people depending on the behavior.
Yeah, it's very useful. Here's a patch for the docs
On Feb 2, 2009, at 12:43 PM, Tom Lane wrote:
Yeah, it's very useful. Here's a patch for the docs about it.
Seems to me that the SELECT reference page is a more appropriate place
for this type of detail. I've applied a patch there.
What about both? The LIMIT page is the first page I'd look
On Feb 2, 2009, at 1:10 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
On Feb 2, 2009, at 12:43 PM, Tom Lane wrote:
Seems to me that the SELECT reference page is a more appropriate
place
for this type of detail. I've applied a patch there.
What about both?
We don't
Howdy,
Is it intentional that `LIMIT NULL` means the same as `LIMIT ALL`? If
so, I'd like to submit a patch to document it, because I've found it
useful in SQL functions:
http://justatheory.com/computers/databases/postgresql/dynamic-limit.html
Thanks,
David
--
Sent via pgsql-hackers
On Jan 29, 2009, at 5:50 PM, Tom Lane wrote:
I don't think we want it to come true. If we treat IS DISTINCT FROM
as a weirdly-named operator then we have to provide an implementation
for every datatype (oh, and another one for IS NOT DISTINCT FROM).
The PITA factor is enormous. Much better to
Howdy,
Shouldn't this work?
postgres=# SELECT 'foo' IS DISTINCT FROM ANY(ARRAY['foo']);
ERROR: syntax error at or near ANY
LINE 1: SELECT 'foo' IS DISTINCT FROM ANY(ARRAY['foo']);
Seems to me that IS DISTINCT FROM is just another operator, like =,
and so it should work with ANUY(),
On Jan 16, 2009, at 8:36 AM, Tom Lane wrote:
One issue here is that plain \d gets less useful because it'll now
include system catalogs. We could add the additional rule that
the above statements apply only when a pattern is specified, and
without a pattern you get just user stuff (so omitting
On Jan 16, 2009, at 9:35 AM, Tom Lane wrote:
So would \df then be equivalent to \dU? Or am I misunderstanding
something?
You mean \dfU? Yes, if there's no pattern.
Yeah, that's what I meant. Thanks. +1.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Jan 16, 2009, at 10:43 AM, Joshua D. Drake wrote:
\df -- all
\dfS-- system only
\dfU-- non-system only
but are we willing to change \d and \dt to work that way too?
Or should we leave them inconsistent?
I would prefer them
Quick patch to mention CITEXT in the parts of the FAQ that discuss
case-insensitive comparisons.
Best,
David
citext_faq.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Quick patch to mention CITEXT in the parts of the FAQ that discuss
case-insensitive comparisons.
Best,
David
citext_faq.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
1201 - 1300 of 1565 matches
Mail list logo
