Christopher Kings-Lynne wrote:
> >>What I would like to see is some builtin functions that give me the
> >>table's DDL, just as pg_dump does. Extra nice would be complementary
> >>functions that also give me skeleton select statements for each table or
> >>view.
> >
> >
> > Yeah, what I first
On Dec 16 08:47, Bruce Momjian wrote:
> I think an int64 is the proper solution. If int64 isn't really
> 64-bits, the code should still work though.
(I'd prefer uint64 instead of an int64.) In src/include/c.h, in
this or that way it'll assign a type for uint64, so there won't
be any problem for bo
Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> writes:
> > Examining why psql won't do sensible stuff with COPY BINARY, I realized
> > that psql still uses PQgetline, which is marked obsolete since 7.4.
> > Is this intentional or just a "never reviewed because it works"?
>
> There wasn't an
Is cardinality the only thing we'd need to worry about? My idea was
actually to track the amount of work normally required by a stored query
plan, and if a query uses that plan but requires a very different amount
of work it's a good indication that we either need to replan or store
multiple plans
Jim C. Nasby wrote:
> Is cardinality the only thing we'd need to worry about? My idea was
> actually to track the amount of work normally required by a stored query
> plan, and if a query uses that plan but requires a very different amount
> of work it's a good indication that we either need to rep
Volkan YAZICI wrote:
> On Dec 16 08:47, Bruce Momjian wrote:
> > I think an int64 is the proper solution. If int64 isn't really
> > 64-bits, the code should still work though.
>
> (I'd prefer uint64 instead of an int64.) In src/include/c.h, in
> this or that way it'll assign a type for uint64, so
Also, can I get a context diff for the patch? See the developers FAQ
for information on how our patch process works. Thanks.
---
Volkan YAZICI wrote:
> On Dec 16 08:47, Bruce Momjian wrote:
> > I think an int64 is the prop
Bruce Momjian writes:
> I think we are at a point that people running on systems with no int64
> support should not expect to get valid return values for >2 billion row
> COPY operations.
I agree, there's no need to work harder on this than changing the
datatype to uint64.
There are some places
Bruce Momjian wrote:
* Flush cached query plans when the dependent objects change,
when the cardinality of parameters changes dramatically, or
when new ANALYZE statistics are available
Wouldn't it also make sense to flush a cached query plan when after
execution it
Lukas Smith <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>
>> * Flush cached query plans when the dependent objects change,
>>when the cardinality of parameters changes dramatically, or
>>when new ANALYZE statistics are available
>
> Wouldn't it also make sense to flush a
Chris Browne wrote:
> Lukas Smith <[EMAIL PROTECTED]> writes:
> > Bruce Momjian wrote:
> >
> >>* Flush cached query plans when the dependent objects change,
> >> when the cardinality of parameters changes dramatically, or
> >> when new ANALYZE statistics are available
> >
> > Wouldn't
Marko Kreen wrote:
> > Maybe we should provide a backslash command in psql for secure
> > password entry, say, \password [username]. This would then ask for
> > the password through a somewhat secure, unlogged channel, encrypt
> > it, and send an ALTER ROLE command to the server.
>
> Letting creat
Lukas Smith <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> * Flush cached query plans when the dependent objects change,
>> when the cardinality of parameters changes dramatically, or
>> when new ANALYZE statistics are available
> Wouldn't it also make sense to flush a cached query plan whe
> Chris Browne wrote:
>> Lukas Smith <[EMAIL PROTECTED]> writes:
>> > Bruce Momjian wrote:
>> >
>> >> * Flush cached query plans when the dependent objects change,
>> >> when the cardinality of parameters changes dramatically, or
>> >> when new ANALYZE statistics are available
>> >
>> > W
> Lukas Smith <[EMAIL PROTECTED]> writes:
>> Bruce Momjian wrote:
>>> * Flush cached query plans when the dependent objects change,
>>> when the cardinality of parameters changes dramatically, or
>>> when new ANALYZE statistics are available
>
>> Wouldn't it also make sense to flush a cached query
15 matches
Mail list logo
