Alvaro Herrera writes:
If people doesn't receive any message regarding the command they
executed, they will execute it again, and again, and they will
eventually wonder what's wrong and start investigating why nothing is
happening.
That is not the case here. The commands still generate the
Peter Eisentraut wrote:
Tom Lane writes:
There are good security arguments not to have it in the default install,
no?
I think last time the only reason we saw was that dump restoring would be
difficult. I don't see any security reasons.
That could be overcome by doing a 'drop
Tom Lane [EMAIL PROTECTED] wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
I found a few notices and warnings that inform you that the command you
are executing has no effect because the object is already in the state
you
want it. I think these are useless, and there is also some
On Saturday 06 September 2003 07:25, Peter Eisentraut wrote:
Alvaro Herrera writes:
If people doesn't receive any message regarding the command they
executed, they will execute it again, and again, and they will
eventually wonder what's wrong and start investigating why nothing is
Andrew Dunstan [EMAIL PROTECTED] writes:
I did see a reference in the archives to a problem with heavy recursion
as a possible security hole. I guess my answer to that would be that if
you are worried about it you should drop the language, but I don't see
this alone as a reason not to
The key value of having both SD vs. GB is scope.
We *do* want to be able to have dictionaries with
scope that is function specific,
statement specific and global (available to all functions).
I do use plpython primarily for running aggregates.
Having the different scopes (if they all worked
Hello,
I have a table with a serial type in it as a record id.
The type of this object comes back as int4 when I query via
pg_type.
How can I distinguish this counter type from just a plain int4?
Peter
---(end of broadcast)---
TIP 6: Have you
Tom Lane [EMAIL PROTECTED] writes:
Mendola Gaetano [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
I've found a number of infelicities in the hash index code that
can't be fixed without an on-disk format change.
How can we avoid this kind of mess for the future ?
Build a time
If the function is defined with ANY*
and you defer typing the arguments until the first reference
then I think you will get what you want with the CASE statement.
If the function is called if( xy, x+1, y), the first reference
is in the argument list and so should be typed there. But if
you
Peter Eisentraut [EMAIL PROTECTED] writes:
Marek Lewczuk writes:
Currently I have big problem with function IF(), below the description
of this function from MySQL manual.
You cannot implement this kind of function, unless you want to create one
version for each data type combination.
As of
pw [EMAIL PROTECTED] writes:
I have a table with a serial type in it as a record id.
The type of this object comes back as int4 when I query via
pg_type.
How can I distinguish this counter type from just a plain int4?
Well, you can't, because serial isn't actually a type in Postgres.
As the
I think I found a solution. Hopefully the system tables don't change
too much in the future.I just used pg_attrdef to tell me which columns
*not* to use.
I hope that's right. It seems to work.
Peter
On Sat, 2003-09-06 at 18:19, Tom Lane wrote:
pw [EMAIL PROTECTED] writes:
I have a table
12 matches
Mail list logo
