Ühel kenal päeval, E, 2007-06-11 kell 22:55, kirjutas Dann Corbit:
-Original Message-
...
I hope someone who truly understands database interfaces will read
this thread and address the issue.
For now we will have to special case postgres in our application
until it is
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 any table
the database should report that the maximum length of the
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 to
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:26:
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
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 the sleep
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 data
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.
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 number
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
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 sleep time depends on
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
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
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.
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
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):
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 it
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 any table
the database should report that
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
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 supporting
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
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 install,
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:
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.
Will
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
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
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
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 problems
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
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?
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:
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 length at
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*
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 some
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, which
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
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
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
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 effort it
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
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
-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
For
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
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, and
-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
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 anything
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
-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,
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
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 always a good
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
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, the
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, I
Ü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 I
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 can
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 a point
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
57 matches
Mail list logo
