If we tries to drop the table on which autovacuum is running, we have to
wait finish of the vacuum. However, the vacuuming effort goes to waste for
the table being dropped or rewritten. Meanwhile, we've already had the
autovacuum killer triggered in CREATE/DROP/RENAME DATABASE commands.
Can we exte
I see... PostgreSQL wants to guess the datatype, given no clear
syntactic information, and perhaps a varchar(n) wouldn't be a valid cast
to some of the possible datatypes.
So, where x = '(1,2)' might be legal for comparing to x, but a field of
type varchar(5) might not be, as in where x = y, wher
Hannu Krosing wrote:
Ühel kenal päeval, T, 2007-06-12 kell 13:40, kirjutas Larry McGhaw:
For what its worth .. Your statement about why we are the first people
to mention this problem really got me thinking. Anyone who would
attempt to write an ODBC driver for Postgres would run into the exact
"Chuck McDevitt" <[EMAIL PROTECTED]> writes:
> Just a curiosity question: Why is the type of a literal '1' "unknown"
> instead of varchar(1)?
Because, for instance, it might be intended as an integer or float or
numeric value. Change the content a little, like '(1,2)' or '12:34',
and maybe it's
Just a curiosity question: Why is the type of a literal '1' "unknown"
instead of varchar(1)?
Wouldn't varchar(1) cast properly to any use of the literal '1'?
What is the benefit of assuming it's an unknown?
---(end of broadcast)---
TIP 7: You ca
Ühel kenal päeval, T, 2007-06-12 kell 13:40, kirjutas Larry McGhaw:
> For what its worth .. Your statement about why we are the first people
> to mention this problem really got me thinking. Anyone who would
> attempt to write an ODBC driver for Postgres would run into the exact
> same issue. So
"Andrew Hammond" <[EMAIL PROTECTED]> writes:
> - Implicit casting of unknown to char(n) or anything else seems rather
> sketchy to me, but I can't see any specific objection, except that...
> - I don't know when the right time to do the cast is. And doing it too
> early seems obviously wrong.
Well
Josh Berkus <[EMAIL PROTECTED]> writes:
>> What's the point? You keep reminding us that your code is middleware
>> that can't assume anything much about the queries you're dealing with.
> Hmmm? I thought that Dann was just talking about constants, and not column
> results. Am I confused?
Well
On 6/12/07, Josh Berkus <[EMAIL PROTECTED]> wrote:
Tom,
> What's the point? You keep reminding us that your code is middleware
> that can't assume anything much about the queries you're dealing with.
> Therefore, I see no real value in fixing up one corner case. Your
> argument about space all
Tom,
> What's the point? You keep reminding us that your code is middleware
> that can't assume anything much about the queries you're dealing with.
> Therefore, I see no real value in fixing up one corner case. Your
> argument about space allocation falls to the ground unless we can
> provide a
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Andrew Hammond wrote:
>> Why? If the legal mumbo-jumbo has already got some precedence as being
>> un-enforcable (even if it's only in a handful of jurisdictions), why
>> give it even a patina of credibility by addressing it in a policy?
> It is alwa
As Dann pointed out we were one of the first companies to port Postgres
to windows many many years ago (7.1 days), and part of that porting work
is in the current postgresql product.
As I pointed out in a prior post, for the ODBC specification at least
(probably others), a maximum upper bound on r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/12/07, Andrej Ricnik-Bay wrote:
On 6/13/07, Andrew Hammond wrote:
> The problem here is that there aren't really very many defined
> defaults, or that these defaults vary (sometimes greatly) between the
> different flavors of UNIX. For example
Andrew Hammond wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/12/07, Tom Lane wrote:
A more serious objection is that any automated tool would probably get it
wrong sometimes, and strip important text.
> I vote 'lets not bother'
Right. I agree with Josh's idea about mentioning li
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> In the case of a SELECT query that selects a fixed constant of any sort,
> it would be a definite improvement for PostgreSQL to give some sort of
> upper maximum.
What's the point? You keep reminding us that your code is middleware
that can't assume any
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/12/07, Tom Lane wrote:
A more serious objection is that any automated tool would probably get it
wrong sometimes, and strip important text.
> I vote 'lets not bother'
Right. I agree with Josh's idea about mentioning list policies in the
subs
Dan,
> Secondly, we
> believe that we should treat the customers the way that we want to be
> treated.
> I think that the PostgreSQL group has managed the first objective, but
> not the second.
I just read this whole thread, and I feel that the sort of comment above is
completely unjustified, a
Dann Corbit wrote:
First a comment:
At CONNX Solutions Inc., we believe sincerely that we should do whatever
is necessary to make our customers prosper. This means creation of
excellent tools and being responsive to customer needs. Secondly, we
believe that we should treat the customers the
> -Original Message-
> From: Larry McGhaw
> Sent: Tuesday, June 12, 2007 1:40 PM
> To: Martijn van Oosterhout
> Cc: Andrew Dunstan; Hannu Krosing; Tom Lane; Alvaro Herrera; Dann
Corbit;
> Gregory Stark; pgsql-hackers@postgresql.org
> Subject: RE: [HACKERS] Selecting a constant question
>
>
First a comment:
At CONNX Solutions Inc., we believe sincerely that we should do whatever
is necessary to make our customers prosper. This means creation of
excellent tools and being responsive to customer needs. Secondly, we
believe that we should treat the customers the way that we want to be
For what its worth .. Your statement about why we are the first people
to mention this problem really got me thinking. Anyone who would
attempt to write an ODBC driver for Postgres would run into the exact
same issue. So I installed the official Postgres ODBC driver, and ran
the identical query
Dave Page <[EMAIL PROTECTED]> writes:
> Josh Berkus wrote:
>> The only additional idea I have is that we ought to simply strip away any
>> e-mail footer over 4 lines from the archives. Not only would this purge
>> the
>> confidentiality footers, it would save us some space in general.
> The e
Josh Berkus wrote:
> The only additional idea I have is that we ought to simply strip away any
> e-mail footer over 4 lines from the archives. Not only would this purge the
> confidentiality footers, it would save us some space in general.
The effort it would take to write some code to extract
On 6/13/07, Andrew Hammond <[EMAIL PROTECTED]> wrote:
The problem here is that there aren't really very many defined
defaults, or that these defaults vary (sometimes greatly) between the
different flavors of UNIX. For example, please tell me:
1) Where should PGDATA default to?
2) How do you want
Tom,
> Doesn't sound like a good idea, but maybe there's a case for a comment
> there saying "these are the most important ones to look at"?
Yeah, probably need to do that. Seems user-unfriendly, but loading a foot gun
by having some options appear twice in the file seems much worse. I'll also
All,
> Perhaps we make a policy that corporate-style ("disclaimered") mail
> is encouraged to seek support via corporate-style channels (e.g. is
> pointed at the commercial support companies). I'm uncomfortable with
> such a policy, but it'd be better than "ignore these nasty corporate
> victims"
Josh Berkus <[EMAIL PROTECTED]> writes:
> On the more hypothetical basis I was thinking of adding a section at the top
> with the 7-9 most common options that people *need* to set; this would make
> PostgreSQL.conf much more accessable but would result in duplicate options
> which might cause so
Tom,
> Do you have a better organizing principle than what's there now?
It's mostly detail stuff: putting VACUUM and Autovac together, breaking up
some subsections that now have too many options in them into grouped.
Client Connection Defaults has somehow become a catchall secton for *any*
US
"Larry McGhaw" <[EMAIL PROTECTED]> writes:
> The statement above is contrary to my actual results. The proper length
> is returned in all non-const cases.
>
> Here is a specific example:
>
> test=# create table test1 ( a varchar(20), b char(10), c integer );
> CREATE TABLE
It's not returning a
That one surprised me as well.
Thanks
lm
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 12, 2007 12:00 PM
To: Larry McGhaw
Cc: Brian Hurt; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Selecting a constant question
Larry McGhaw wrote:
> F
Larry McGhaw wrote:
For constant '123'::varchar(3) libpq returns the following:
Pqfsize returns -1
Pqfmod returns -1
That one certainly looks odd.
cheers
andrew
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
The problem here is that there aren't really very many defined
defaults, or that these defaults vary (sometimes greatly) between the
different flavors of UNIX. For example, please tell me:
1) Where should PGDATA default to?
2) How do you want to handle logging output from the postmaster? There
ar
>> What I don't understand is *why* it's complaining about the constant
column
>> and not, for example, any other variable length column. There are a
very small
>> number of cases where a useful length is returned, 99% of the time it
doesn't,
>> yet you're obviously not get any performance probl
Larry McGhaw wrote:
I'm really frustrated by this process I'm not trying to attack anyone
here. I'm just surprised that no one will even entertain the idea that
this is an issue that needs to be addressed.
Instead nearly all of the responses have been attacking the applications
that rely on th
Hi,
Nobody is tring to attack anyone, but we're all surprised this is an
issue since you're the first person to have mentioned it. I have some
a query to test below:
On Tue, Jun 12, 2007 at 10:21:09AM -0700, Larry McGhaw wrote:
> We noticed inexplicably that when we used a constant with a postgre
I'm really frustrated by this process I'm not trying to attack anyone
here. I'm just surprised that no one will even entertain the idea that
this is an issue that needs to be addressed.
Instead nearly all of the responses have been attacking the applications
that rely on the metadata.
Let me bac
Tom Lane wrote:
> This patch appears to have randomly changed the format of the resultmap
> file. Please either undo that, or update the documentation
> (regress.sgml) to describe what it is now.
Not randomly - it needs to be able to use paths including /, so it can't
be a separator anymore.
Wil
This patch appears to have randomly changed the format of the resultmap
file. Please either undo that, or update the documentation
(regress.sgml) to describe what it is now.
regards, tom lane
---(end of broadcast)---
TIP 3:
Alvaro Herrera wrote:
> There is a remaining problem though, which is that it doesn't work at
> all on VPATH builds. The problem seems to be that we are neglecting to
> symlink the files into the builddirs. I am looking into that.
The "problem" is that the files are only symlinked on "make inst
Hi,
Quick report from the front lines.
I've been IM'ing with Magnus and he already fixed most problems with the
regression tests. The buildfarm should slowly start turning green
again.
There is a remaining problem though, which is that it doesn't work at
all on VPATH builds. The problem seems
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> I don't have much insight into the operator classes and operator families
> and how they work. Where should I look for the related code ?
Primary opclass members are stored right in the Relation data struct for
you. Since (I trust) you're only suppor
David Fetter wrote:
On Fri, Jun 08, 2007 at 08:12:22PM -0500, Jim C. Nasby wrote:
On Tue, Jun 05, 2007 at 05:52:39PM -, Andrew Hammond wrote:
On Jun 5, 9:19 am, [EMAIL PROTECTED] (Alvaro Herrera) wrote:
Zdenek Kotala wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Is th
Larry McGhaw wrote:
Again, the issue is not our tool, but the deficiency in libpq/postgres
... even mysql gets its right .. why not Postgres?
Its not hard for a database to report metadata properly.
if I issue a sql statement:
select '123' from
the database should report that the maximum
On Tue, Jun 12, 2007 at 12:47:55PM +0200, Zeugswetter Andreas ADI SD wrote:
> I think this focuses too much on those cases where it is not possible.
> When it is not feasible like with a text column, clients deal with it
> already (obviously some better than others).
> It is for those cases where
Hi,
As per HOT design, a necessary condition to do HOT updates is
that an index column must not be updated. I am invoking the type
specific equality operator to compare two index columns, something
like this (which I think I had copied from ri_KeysEqual(), but that too have
changed now):
Magnus Hagander wrote:
On Tue, Jun 12, 2007 at 12:23:50PM +0200, Zdenek Kotala wrote:
Alvaro Herrera wrote:
Zeugswetter Andreas ADI SD escribió:
The launcher is set up to wake up in autovacuum_naptime
seconds
at most.
Imho the fix is usually to have a sleep loop.
This is what we have. The
Heikki Linnakangas wrote:
> Actually, if you're in such a high throughput, client-side CPU-intensive
> situation that this makes any difference, why are you copying the value
> to another buffer in the first place? Just access it directly in the
> libpq buffer returned by PQgetvalue, and move on.
Zeugswetter Andreas ADI SD wrote:
Thats exactly the point. Consider
select mytext from mytable ;
How can PostgreSQL possibly know the maximum length of the
returned values *before* it has scanned the whole table?
I think this focuses too much on those cases where it is not possible.
When it i
> Thats exactly the point. Consider
> select mytext from mytable ;
>
> How can PostgreSQL possibly know the maximum length of the
> returned values *before* it has scanned the whole table?
I think this focuses too much on those cases where it is not possible.
When it is not feasible like with a
On Tue, Jun 12, 2007 at 12:23:50PM +0200, Zdenek Kotala wrote:
> Alvaro Herrera wrote:
> >Zeugswetter Andreas ADI SD escribió:
> >>>The launcher is set up to wake up in autovacuum_naptime
> >>seconds
> >>>at most.
> Imho the fix is usually to have a sleep loop.
> >>>This is what we hav
Dann Corbit wrote:
-Original Message-
From: Hannu Krosing [mailto:[EMAIL PROTECTED]
Since libpq function PQfsize returns -2 for all constant character
strings in SQL statements ... What is the proper procedure to determine
the length of a constant character column after query execution b
"Larry McGhaw" <[EMAIL PROTECTED]> writes:
> The database *knows* this size of the char constant (obviously), and
> should report the size via a metadata call, as all other relational
> databases do.
I'm not even clear whether you and Dan are talking about the same thing. He's
talking about the n
Alvaro Herrera wrote:
Zeugswetter Andreas ADI SD escribió:
The launcher is set up to wake up in autovacuum_naptime
seconds
at most.
Imho the fix is usually to have a sleep loop.
This is what we have. The sleep time depends on the schedule
of next vacuum for the closest database in time. If
> > Again, *all* other major relational databases do this ...
> even blob fields have a maximum length reported from the database.
>
> So what are you doing with the max length? Not all data types
> and values have a meaningful max length, so you have to be
> able to deal with variable length
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > No, I meant a "while (sleep 1(or 10) and counter < longtime) check for
> > exit" instead of "sleep longtime".
>
> Ah; yes, what I was proposing (or thought about proposing, not sure if I
> posted it or not) was putting a upper limit of 10 seconds in
Larry McGhaw wrote:
Again, *all* other major relational databases do this ... even blob fields
have a maximum length reported from the database.
So what are you doing with the max length? Not all data types and values
have a meaningful max length, so you have to be able to deal with
variabl
On Tue, Jun 12, 2007 at 09:57:17AM +0200, Michael Meskes wrote:
> On Mon, Jun 11, 2007 at 07:03:05PM +0200, Magnus Hagander wrote:
> > I get the following error when trying to build the sql/parser.pgc test:
> > c:\prog\pgbin\pgsql\bin\ecpg --regression -o parser.c parser.pgc
> > parser.pgc
On Mon, Jun 11, 2007 at 07:03:05PM +0200, Magnus Hagander wrote:
> I get the following error when trying to build the sql/parser.pgc test:
> c:\prog\pgbin\pgsql\bin\ecpg --regression -o parser.c parser.pgc
> parser.pgc:26: ERROR: syntax error at or near "NULLS"
>
> Any pointers for where
Again, the issue is not our tool, but the deficiency in libpq/postgres ... even
mysql gets its right .. why not Postgres?
Its not hard for a database to report metadata properly.
if I issue a sql statement:
select '123' from
the database should report that the maximum length of the 1st colum
59 matches
Mail list logo
