> We have a database specification in .pgpass:
>
> hostname:port:database:username:password
>
> What is the purpose of 'database' since username/password combinations
> are global, not per database? I would like to documents its purpose.
There is the GUC parameter db_user_namespace. Just fo
> Hmm... it is true that average will produce the same results on any
> ordering of the same set of input values, though. Perhaps the word
> "partition" emcompass that, though then again maybe not.
>
> I'd be happy to fix this if I understand what to fix it to.
I wish I knew how to rephrase it so
> On Wed, Sep 22, 2010 at 6:03 AM, Dennis Björklund wrote:
> But I confess that I'm sort of murky on how ORDER affects the window
> frame, or how to rephrase this more sensibly.
The rows included in the calculation of the window function are per default
RANGE BETWEEN UNBOUNDED
In
http://www.postgresql.org/docs/9.0/static/tutorial-window.html
it say
"Although avg will produce the same result no matter what order it
processes the partition's rows in, this is not true of all window
functions. When needed, you can control that order using ORDER BY within
OVER."
While it
ther have long commands so one can write
\describe_table foo
and have the tab completion work for these of course (only for the long
commands, the \dt and such does not belong in completion).
The information schema is nice, but it's not what I want to use at
we fix it by forcing LC_CTYPE to the database
> encoding during startup?
What does database encoding has to do with error messages and the display
character set?
--
/Dennis Björklund
---(end of broadcast)---
TIP 3: if posting/reading throug
stion. Why is --enable-nls needed? Most other programs default
to that.
--
/Dennis Björklund
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
#x27;s something that I might spend some time on trying to fix.
--
/Dennis Björklund
---(end of broadcast)---
TIP 8: explain analyze is your friend
hat I want is that future fedora/redhat versions work out of the box.
Most people use distributions and it's no fun to translate postgresql if
people are annoyed with the result :-)
--
/Dennis Björklund
---(end of broadcast)---
TIP 6: Have you se
On Wed, 7 Jan 2004, Bruno Wolff III wrote:
> > ps I've just changed my email name to my real name which is Dennis
> > Björklund.
>
> It still isn't legal to use non US ASCII characters in headers. There
> is an encoding scheme that can be used for the subject heade
time especially on
the catalog parts. That is a very fragile part of pg and it's not fun to
make changes there. There are assumptions in the code that is not clear to
a new coder.
ps I've just changed my email name to my real name which is Dennis
Björklund. I did that 5 years ago (sti
On Sat, 30 Aug 2003, Tom Lane wrote:
> > I don't understand why the serial columns sequence should be visible as
> > other sequences.
>
> Backwards compatibility, if nothing else. Are you prepared to break
> every existing dump file that has
> CREATE TABLE ser (f1 serial);
> SELECT p
On Sat, 30 Aug 2003, Tom Lane wrote:
> It'd probably be reasonable to rename only those sequences that are
> connected to the target table/column by internal dependencies --- this
> indicates that they were created by a SERIAL column definition and not
> by manual operations.
I don't understand w
On Wed, 27 Aug 2003, Kevin Brown wrote:
> There are some cases where it's extremely useful for PostgreSQL to
> accept dates of any format it knows about (ambiguities should be
> resolved either by looking at the current DateStyle or, failing that, by
> applying the recognition in a well-defined or
I'm looking over the last bits of translations of pg. Is it to late to
update the translations for 7.4? Should I work on the cvs head version or
is there some branching going on?
--
/Dennis
---(end of broadcast)---
TIP 7: don't forget to increas
On Sun, 3 Aug 2003, Tom Lane wrote:
> I added code to inline_function to stop inlining if a parameter
> expression to be substituted multiple times has cost greater than
> 10*cpu_operator_cost (which roughly means that it contains more than
> 10 operators or functions).
When is this inlining taki
I had a bug in one of my queries that wasn't detected by pg because if
filled in the from clause by itself. Take for example a querie like
select foo.a;
which I guess is transformed to
select foo.a
from foo;
Is this really a good thing to do? Is it part of the standard? Can it be
turned of? In
On Sat, 28 Jun 2003, Joe Conway wrote:
> > Do I need to do something to get new language files?
>
> causing me problems. Did a "cvs add" get missed somewhere, or am I doing
> something wrong?
Yes, a couple of cvs add was forgotten.
Peter made an update with the comment "Merge PO file updates f
On Wed, 25 Jun 2003, Paul Ramsey wrote:
> Ignorance on my part, probably. You mentioned elog() so I grepped for it
> and found lots of this stuff:
>
> elog(FATAL, "data directory %s was not found", checkdir)
> elog(FATAL, "could not read permissions of directory %s: %m",
>checkd
On Mon, 16 Jun 2003, Peter Eisentraut wrote:
> > However, if you want to produce a utf-8 file, how should that work with
> > respect to gettext()? If the message catalog is in latin1 then we need to
> > know that and convert that into utf-8.
>
> I don't think all gettext implementations support a
On Mon, 16 Jun 2003, Oleg Bartunov wrote:
> I thought I could specify different encodings
> for different databases and these encodings will be used in text operations
> (sort, upper,lower), not just for conversion.
En encoding does not imply any sort order. UTF-8 can be used to store
strings in
I've fixed the problems in psql that was there before:
* psql alters the strings in a PQresult
* psql sends non validating strings to server
This is however not the solution to the general problem with client
encodings. When you normally run psql in a terminal, the encoding used by
that termi
Why do we have SQL_ASCII?
I could understand it if we only could store 7-bit strings there. But
SQL_ASCII lets you store 8-bit values. Should I understand SQL_ASCII
simply as 8-bit strings of unknown charset?
In the first database I created I used it to store latin1 strings, and
that was a mist
On Thu, 12 Jun 2003, Tom Lane wrote:
> I think the string ought to be copied first ... although that might
> create memory-leak problems. Could you take a look at fixing this,
> while you're in the area?
Sure.
> I can whitelist you if you have a stable IP address --- is that a static
> or dynam
On Thu, 12 Jun 2003, Tom Lane wrote:
> I'd call that a bug in psql. Where do you see it happening exactly?
It's the utf-8 validation function (mbvalidate) that removes characters
that it does not understand.
> No, I think the return value ought to be treated as const char *.
> We're hesitant t
I've been looking into the code of psql to fix a problem with charsets and
noticed that psql changes the strings it gets back from functions like
PQfname() and PQgetvalue().
I can't find in the docs anything that says that it is okay to alter the
returned string. It works since it's allocated and
On Tue, 10 Jun 2003, Peter Eisentraut wrote:
> we should try to keep the (translated) column headers within the client,
> to side-step this issue. Do you want to investigate that?
That is the obvious solution, there is no real need to send the strings to
the server in the first place.
The probl
I've been playing with character encodings and found a problem/bug. I
still use 7.3.2, so it's possible (but I think not) that some of this have
been fixed.
When you run psql with a different language then english the strings are
usually in a character set that is not pure ascii. For example to
re
There is no declaration of charset in the main webpage. Something like
would be nice. What is worse is that there are several charsets used. In
the International part I have to set mozilla to use utf-8 for it to be
rendered correctly and in the Event part I have to tell mozilla to use
iso-8859-1
What is the translation stats on
http://webmail.postgresql.org/~petere/nls.php
based on? I've not updated my translation in a long time (since 7.3.0)
and it's still at 100% (except the big file that wasn't 100% before).
Seems strange that there havn't been any new or changed strings since
t
On Fri, 3 Jan 2003, Justin Clift wrote:
> Very Cool. The URL for the .pgpass stuff is:
>
> http://developer.postgresql.org/docs/postgres/libpq-files.html
There is a typo on that page. First it talkes about the file .pgpass and
then it says: "chmod 0600 .pgaccess".
I had no idea that one could
On 3 Dec 2002, Hannu Krosing wrote:
> the standard way of doing it would be SQL99's WITH :
Great! I havn't looked too much at sql99 yet so I've missed this. It's
exactly what I want. Now I know what I will use in the future (when it's
all implemented).
--
/Dennis
---
On Tue, 3 Dec 2002, Magnus Naeslund(f) wrote:
> Now convert this query so that it only evaluates the date_part thing
> ONCE:
>
> select t.id, date_part('days',now()-t.stamp) from table_name t where
> date_part('days',now()-t.stamp) > 20;
Something like this could work:
select *
from (select t
On Sun, 10 Nov 2002, Tom Lane wrote:
> In the last episode of this long-running issue, we decided that life
> would be better if we make small-enough integer constants be initially
> typed as int2 rather than int4, and then auto-promote them up to int4
> when necessary.
What kind of type system d
Is there a planned string freeze for postgresql?
There was a (good) change some weeks ago that altered lots of witespace.
Remember that it's enough to change a single space to make that
translation of that string not work. To do "psql --help" and get half the
entries in swedish and half in english
35 matches
Mail list logo
