I said:
> OpenBSD's tcl package is broken, then. It's their responsibility to put
> the necessary compiler flags into tclConfig.sh, not the responsibility
> of every Tcl-using software to second guess where the include files are.
After thinking about this a little more, I'm confused again. How
Robert Hentosh <[EMAIL PROTECTED]> writes:
> It fails with the following error when it compiles src/pl/tcl/pltcl.c:
> pltcl.c:38: tcl.h: No such file or directory
> This works on my linux box since tcl.h is in /usr/include but on OpenBSD it is
>located in /usr/local/include/tcl8.3/tcl.h
OpenB
POSTGRESQL BUG REPORT TEMPLATE
Your name : Hentosh
Your email address : [EMAIL PROTECTED]
Syste
"Jan Branbergen" <[EMAIL PROTECTED]> writes:
> When i do a "NSERT INTO screen_filter_field( screen_filter_id,
> screen_field_id, seqno, visible, orderno ) SELECT 182, id, seqno, visible,
> orderno FROM screen_field WHERE screen_id = 1" i get a permission denied on
> table screen_field; i have sele
"Jan Branbergen" <[EMAIL PROTECTED]> writes:
> i have constraints defined on the tables to force ref integrity, but nothing
> else. i can send my schema if you would like.
If you have a foreign key reference from screen_filter_field to
screen_filter, that would explain it --- but I'd expect you'd
> "VK" == Vivek Khera <[EMAIL PROTECTED]> writes:
> "PE" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
PE> Sure it does. See 'var/run/ld[-elf].so.hints'.
VK> But /var/run is not guaranteed to survive reboot. "man hier" has this
VK> to say about it:
One more thing... /etc/rc _explici
> From my point of view, NULL is neither bigger, nor smaller, you can't
> compare it with a number.
> So it just comes at the end if you sort at all.
Well, I know you can't compare null in, for example, WHERE clause. But if
we want to sort data in some way, I would like Postgres to behave in any,
POSTGRESQL BUG REPORT TEMPLATE
Your name : Jan Branbergen
Your email address : [EMAIL PROTECTED]
> "PE" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
PE> Sure it does. See 'var/run/ld[-elf].so.hints'.
But /var/run is not guaranteed to survive reboot. "man hier" has this
to say about it:
run/ system information files describing various info
about system si
> "BM" == Bruce Momjian <[EMAIL PROTECTED]> writes:
BM> Got it. I recommend changing 'su -l' to 'su -m' to preserve the
BM> environment. How does that sound?
Just tried it and it works ok. The only issue I can think of is if
root has some secret info in the environment, that it will now b
> "PE" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Also, the following line in the start action of the sript is useful:
>>
>> /sbin/ldconfig -m $prefix/lib
PE> You ought to run this once, not every time the system starts.
No, FreeBSD does *not* cache this info. You need to run it o
Thomas Lockhart wrote:
>>When I execute the following query:
>>SELECT DISTINCT title FROM division ORDER BY UPPER(title);
>>I get:
>>ERROR: For SELECT DISTINCT, ORDER BY expressions must appear in target list
>>If I remove DISTINCT, the query works fine.
>>Is this illegal or a known bug?
>>
>
Tom Lane wrote:
>"J.R. Onyschak" <[EMAIL PROTECTED]> writes:
>
>>When I execute the following query:
>>SELECT DISTINCT title FROM division ORDER BY UPPER(title);
>>
>>I get:
>>ERROR: For SELECT DISTINCT, ORDER BY expressions must appear in target list
>>
>>If I remove DISTINCT, the query works
Sure,
I have about 70 tables, each vacuum prints out something like this per
table. You'll notice it prints stuff for each index also.
postgres[23034]: [566] DEBUG: --Relation test--
postgres[23034]: [567-1] DEBUG: Pages 1: Changed 1, reaped 1, Empty 0,
New 0; Tup 3: Vac 1, Keep/VTL 0/0, Cr
14 matches
Mail list logo
