Andrew Dunstan kirjutas L, 06.09.2003 kell 16:14:
> 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
> >dif
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 t
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
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 se
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
corr
> "BM" == Bruce Momjian <[EMAIL PROTECTED]> writes:
BM> Vivek, you reported recently that increasing sort_mem and
BM> checkpoint_segments increased performance. Can you run a test to see
BM> how much of that improvement was just because of increasing
BM> checkpoint_segments?
i was thinking j
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 fut
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( x>y, x+1, y), the first reference
is in the argument list and so should be typed there. But if
you pas
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
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
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
>
"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
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 language'
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
14 matches
Mail list logo
