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.
Y
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
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
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 pro
On 2013-04-26 12:17, D'Arcy J.M. Cain wrote:
> On Fri, 26 Apr 2013 11:01:28 +0200
> CR Lender wrote:
>> create table countries (
>> codechar(2) not null primary key,
>
> Isn't this redundant? Primary keys are always NOT NULL.
Yes, I fo
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', f
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 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
>&
On 2013-03-28 20:44, Kevin Grittner wrote:
> CR Lender 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 extre
On 2013-03-28 13:11, Martín Marqués wrote:
> 2013/3/27 CR Lender :
>> 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)a
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 vacu
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 vacuum,
12 matches
Mail list logo
