On 2013-09-19 02:01, Juan Daniel Santana Rodes wrote:
I am programming a procedure in plpgsql language and it must return a
boolean response. The procedure must return TRUE if the query is
semantically correct and if not correct, return FALSE. This must be
done without running the query.
You
On 2013-05-14 19:32, Paul Jungwirth wrote:
The UTF-8 encoding for a pound sign is 0xc2a3, not just 0xa3. You
might want to make sure your PHP file is correct.
Just for the record, the Unicode code point for the pound symbol (£) is
actually 0x00A3. 0xC2A3 is the Hangul syllable Syuh (슣).
- crl
On 2013-05-15 00:31, Chris Angelico wrote:
Which, in UTF-8, is represented by the byte sequence C2 A3. (The
latter would be represented as EC 8A A3.)
Right, my bad.
I read Unicode instead of UTF-8.
- crl
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
Sorry for the late reply, I had to give this some time to digest.
I'm still trying to wrap my head around the concept that triggers don't
belong to a table...
On 2013-04-26 17:15, Richard Huxton wrote:
On 26/04/13 10:01, CR Lender wrote:
I think this is more a problem of terminology rather than
I have two tables with countries and persons living in those countries:
create table countries (
codechar(2) not null primary key,
eu boolean not null
);
insert into countries values
('AR', false),
('BE', true),
('CH',
On 2013-04-26 12:17, D'Arcy J.M. Cain wrote:
On Fri, 26 Apr 2013 11:01:28 +0200
CR Lender crlen...@gmail.com wrote:
create table countries (
codechar(2) not null primary key,
Isn't this redundant? Primary keys are always NOT NULL.
Yes, I forgot to remove
On 2013-04-09 00:09, Kevin Grittner wrote:
I'm not sure that what we're doing now is correct, but updating
things as if a normal vacuum had been done would *not* be the thing
to do. For starters, VACUUM FULL blows away the free space map and
visibility map for a table. Among other things,
On 2013-03-31 18:31, CR Lender wrote:
On 2013-03-28 20:44, Kevin Grittner wrote:
CR Lender crlen...@gmail.com wrote:
I've read the manual more carefully now, and I can't see any mention of
what VACUUM does that VACUUM FULL does not. The point about extreme
maintainance is taken, but from what
On 2013-03-28 20:44, Kevin Grittner wrote:
CR Lender crlen...@gmail.com wrote:
The database is running on PostgreSQL 8.3.6.
I've read the manual more carefully now, and I can't see any mention of
what VACUUM does that VACUUM FULL does not. The point about extreme
maintainance is taken
On 2013-03-28 13:11, Martín Marqués wrote:
2013/3/27 CR Lender crlen...@gmail.com:
In this case I was only trying to make sense of an existing database
(8.3). The statistics in pg_stats were way off for some tables, so I
wanted to see if (auto)vacuum and (auto)analyze were being run
On 2013-03-26 19:28, Kevin Grittner wrote:
Why are full vacuums excluded from this statistic? It looks like there's
no way to get the date of the last manual vacuum, if only full vacuums
are performed.
Because FULL is a bit of a misnomer -- there are important things a
non-FULL vacuum does
According to the manual (9.1), pg_stat_get_last_vacuum_time() returns
timestamptz | Time of the last non-FULL vacuum initiated by the
| user on this table
Why are full vacuums excluded from this statistic? It looks like there's
no way to get the date of the last manual
12 matches
Mail list logo
