Hello.
We are currently redesigning a medium/large office management web
application. There are 75 tables in our existing PostgreSQL database,
but that number is artificially low, due to some unfortunate design choices.
The main culprits are two tables named "catalog" and "catalog_entries".
They
Thanks everybody for your comments.
On 2013-03-15 16:03, François Beausoleil wrote:
> Keeping a meaningless ID is not a problem in and of itself. It makes
> it easier to edit records from the UI, since you can reference the ID in
> the UPDATE and DELETE statements, without fear of colliding with
>
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,
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
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-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-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-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,
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-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
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-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
On 23/06/09 03:44, Scott Marlowe wrote:
> On Mon, Jun 22, 2009 at 4:51 PM, Gerry Reno wrote:
>> Londiste is beta. The fact that Skype uses it is because it's part
>> of Skytools which is their product. They may want to run their own
>> beta stuff. I don't.
>
> So, if they said it was general rel
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
Hi.
I'm using PostgreSQL 8.3 with PHP's "pgsql" module (libpq 8.3.7). When
the server's standard_conforming_strings setting is off (this is
currently still the default, I believe), I use something like this to
escape strings:
if ($escWildcards) {
$str = strtr($str, array("%" => '\%', "_" =>
Tom,
thanks for your reply.
On 24/04/09 00:56, Tom Lane wrote:
>> if ($escWildcards) {
>> $str = strtr($str, array("%" => '\%', "_" => '\_'));
>> }
>> return "E'" . pg_escape_string($str) . "'";
>
> The above cannot possibly work. pg_escape_string is generating what it
> supposes to b
On 24/04/09 14:49, Daniel Verite wrote:
> It works for me:
>
> $ php -e
> echo phpversion(), "\n";
> $c=pg_connect("dbname=mail user=daniel host=/tmp port=5000");
> pg_query("SET standard_conforming_strings=off");
> echo pg_escape_string('toto\titi'), "\n";
> pg_query("SET standard_conforming_str
Hello.
We've recently discovered a bug in our code that resulted in COMMITs
without BEGINs, and our client saw "no transaction in progress" warnings
in his log file. What worries me is that we didn't discover this problem
during development - the warning doesn't show up in our logs. We're both
usi
On 07/05/09 15:58, Tom Lane wrote:
> What seems most likely is that you're looking at the wrong log file.
> Recheck the "where to log" settings.
Thanks, Adrian and Tom,
you were right, I wasn't looking at the correct file.
My postgresql.conf has:
log_directory = '/var/log/postgresql'
log_filenam
On 07/05/09 16:56, Adrian Klaver wrote:
>> The server startup messages were in this file (which is why I
>> assumed it was the correct one), but for some reason after a
>> restart the logs were created as
>>
>> /var/log/postgresql/postgresql-8.3-main.log.1241706461
[...]
> is done in the zone spec
On 07/05/09 18:26, Tom Lane wrote:
> Scott Mead writes:
>> How did you restart postgres? I'm guessing that you're using a
>> distribution provided package. If you're using the /etc/init.d
>> scripts from that package, it's likely that the startup script is
>> redirecting stderr and that the syst
On 08/05/09 16:43, Conrad Lender wrote:
> stderr to stdin to capture warnings and errors:
That should be "stderr to stdout", of course.
- Conrad
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql
On 23/05/09 06:05, Rodrigo E. De León Plicet wrote:
>>> Is there a better way?
>>
>> Yeah, natural keys.
>
> +1.
>
> Also, what Ben described reeks of EAV.
>
> Ben, please read:
>
> http://joecelkothesqlapprentice.blogspot.com/2006/04/using-one-table-vs-many.html
Ah yes, the great Celko. I ha
On 23/05/09 09:34, Scott Marlowe wrote:
> I have a great deal of respect for Celko. I don't always agree with
> everything he says, but most of it makes a lot of sense to me.
I didn't intend any disrespect to Joe Celko. I have read a number of his
articles, which tend to be well written and info
On 26/05/09 20:48, Benjamin Smith wrote:
> "A deep unwavering belief is a sure sign that you're missing
> something." -- Unknown
>
> I had no intention of sparking an ideological discussion.
I know, my apologies for going off-topic. I just had a deja-vu when I
saw Celko's article about EAV disast
Hi folks
If I want to experiment with SSL, it sounds like I need the 7.1
beta. Where do I get it?
-- Paul Lender
Paul A. Lender
University of Minnesota Department of Orthopaedic Surgery
420 Delaware St. S.E., MMC 492 Mayo
Minneapolis MN 55455
Voice
27 matches
Mail list logo
