Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Using libpq PQconnect function, what is the syntax for the 'options'
entry in the conninfo?
I think it's stuck straight into the backend command line, so whatever
you read in the 'postgres' reference page applies.
I think the docs should be
Thomas Hallgren [EMAIL PROTECTED] writes:
When making PL/Java dynamically adapt to the setting of
integer-datetimes, I too was bitten by this bug. Is it safe to assume
that the fix for this will arrive in 8.1.0?
I believe Teodor already committed the change in CVS HEAD.
Using libpq PQconnect function, what is the syntax for the 'options'
entry in the conninfo?
I think it's stuck straight into the backend command line, so whatever
you read in the 'postgres' reference page applies.
Oh, I thought it was for setting GUCs at connect time. Is that
possible? I
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Using libpq PQconnect function, what is the syntax for the 'options'
entry in the conninfo?
I think it's stuck straight into the backend command line, so whatever
you read in the 'postgres' reference page applies.
Oh, I thought it was for
Bruno Wolff III [EMAIL PROTECTED] writes:
The case I was thinking of were datatypes without a defined ordering
where max and min wouldn't be usable. But if GROUP BY was going to
changed to allow any columns if the primary key was used in the GROUP
BY clause, I can't see any use for those
On Fri, 11 Mar 2005 10:37:13 +1300, Mark Kirkwood
[EMAIL PROTECTED] wrote:
Firebird 1.5.1 FreeBSD 5.3
[correct results]
Interbase 6.0:
SQL create table tab (col integer);
SQL select 1 from tab having 1=0;
SQL select 1 from tab having 1=1;
0---:-)
SQL
Maybe we make the assumption that all OS will
implement fd as an array index
The POSIX spec requires open() to assign fd's consecutively from zero.
http://www.opengroup.org/onlinepubs/007908799/xsh/open.html
With all due respect, PostgreSQL now runs natively on Win32. Having a
POSIX-only
On 14 Mar 2005, Greg Stark wrote:
select distinct on (x) x,y,z
order by x,y,z
You can do the equivalent:
select x, first(y), first(z)
order by x,y,z
group by x
But you can also handle the more general case like:
select x, first(y), first(z), avg(a), sum(s)
order by x,y,z
Ühel kenal päeval (neljapäev, 10. märts 2005, 20:07+0200), kirjutas
Ioannis Theoharis:
Hi,
i have a table:
create table triples(
att0 varchar(1000),
att1 int4,
att2 varchar(20),
att3 varchar(1000)
)
My table has 990 raws.
The (possibly wrong) way, with
=?windows-1250?Q?Miroslav_=8Aulc?= [EMAIL PROTECTED] writes:
As there are a lot of varchar(1) in the AdDevicesSites table, wouldn't
be helpful to change them to char(1)? Would it solve the variable-width
problem at least for some fields and speed the query up?
No, because char(1) isn't
[EMAIL PROTECTED] writes:
The POSIX spec requires open() to assign fd's consecutively from zero.
http://www.opengroup.org/onlinepubs/007908799/xsh/open.html
With all due respect, PostgreSQL now runs natively on Win32.
... using the POSIX APIs that Microsoft so kindly provides.
fd.c will
=?windows-1250?Q?Miroslav_=8Aulc?= [EMAIL PROTECTED] writes:
Tom Lane wrote:
Actually, we already had a pending patch (from Atsushi Ogawa) that
eliminates that particular O(N^2) behavior in another way. After
applying it, I get about a factor-of-4 reduction in the runtime for
Miroslav's
Dennis Bjorklund [EMAIL PROTECTED] writes:
The standard (sql2003) have what is called windows where one can do these
things and much more.
OLAP functions would be very nice. But they're not the same thing. In fact
that's precisely *why* they would be really nice. They allow you to do things
On 14 Mar 2005, Greg Stark wrote:
SELECT ROW_NUMBER() OVER bar AS num,
x,
avg(a) OVER bar,
sum (a) OVER bar
FROM foo
WINDOW bar AS PARTITION BY x ORDER BY x, y, z;
Note that as you said, this returns just as many records as are in the
original table. The OLAP
[EMAIL PROTECTED] writes:
The POSIX spec requires open() to assign fd's consecutively from zero.
http://www.opengroup.org/onlinepubs/007908799/xsh/open.html
With all due respect, PostgreSQL now runs natively on Win32.
... using the POSIX APIs that Microsoft so kindly provides.
fd.c will
Dennis Bjorklund [EMAIL PROTECTED] writes:
They are aggregate functions, the avg() is a window aggregate function
according to the standard. It runs over all values in the same partition.
-- albeit functions that use data from other records other
than the one being output.
Yes, and
[EMAIL PROTECTED] writes:
That is hardly anything that I would feel comfortable with. Lets break
this down into all the areas that are ambiguous:
There isn't anything ambiguous about this, nor is it credible that there
are implementations that don't follow the intent of the spec. Consider
the
On Mon, Mar 14, 2005 at 02:53:36AM -0500, Tom Lane wrote:
Probably the first thing to do is look around at the plausible users of
this thing and see what they'd find most convenient.
This may be totally irrelevant:
Our current load distributors, like pgpool, have no way of knowing the
side
=?ISO-8859-2?Q?Miroslav_=A9ulc?= [EMAIL PROTECTED] writes:
[ concerning a deeply nested LEFT JOIN to get data from a star schema ]
So I have some results. I have tested the query on both PostgreSQL 8.0.1
and MySQL 4.1.8 with LIMIT set to 30 and OFFSET set to 6000. PostgreSQL
result is
Michael Adler [EMAIL PROTECTED] writes:
Our current load distributors, like pgpool, have no way of knowing the
side effects of backend functions. It would be interesting if the
client could send each potential query to the master saying, execute
this query if there are side effects, otherwise
Nicolai Tufar wrote:
On Thu, 10 Mar 2005 19:21:41 -0500 (EST), Bruce Momjian
pgman@candle.pha.pa.us wrote:
The CVS-tip implementation is fundamentally broken and won't work even
for our internal uses. I've not wasted time complaining about it
because I thought we were going to replace
=?windows-1250?Q?Miroslav_=8Aulc?= [EMAIL PROTECTED] writes:
seriously, I am far below this level of knowledge. But I can contribute
a test that (maybe) can help. I have rewritten the query so it JOINs the
varchar() fields (in fact all fields except the IDPK) at the last INNER
JOIN. Though
Bruce Momjian pgman@candle.pha.pa.us writes:
I am wondering if we should just process long long args and %$ args,
and pass everything else to the native snprintf.
AFAICS this is a non-starter --- how will you construct the call to
snprintf? Or even vsnprintf? C doesn't provide the tools you
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I am wondering if we should just process long long args and %$ args,
and pass everything else to the native snprintf.
AFAICS this is a non-starter --- how will you construct the call to
snprintf? Or even vsnprintf? C doesn't
Bruce Momjian pgman@candle.pha.pa.us writes:
Is there no way to create a va_arg va_list structure in C?
Exactly. The standard lets you *read out* from such a structure,
but there's no provision for creating one on-the-fly.
regards, tom lane
[EMAIL PROTECTED] writes:
That is hardly anything that I would feel comfortable with. Lets break
this down into all the areas that are ambiguous:
There isn't anything ambiguous about this, nor is it credible that there
are implementations that don't follow the intent of the spec.
How do you
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
That is hardly anything that I would feel comfortable with. Lets break
this down into all the areas that are ambiguous:
There isn't anything ambiguous about this, nor is it credible that there
are implementations that don't follow
My copy of APUE says on page 49: The file descriptor returned by open
is the lowest numbered unused descriptor. This is used by some
applications to open a new file on standard input, standard output, or
standard error.
Yes, I'll restate my questions:
What is meant by unused? Is it read to
[EMAIL PROTECTED] wrote:
The point is that this *is* silly, but I am at a loss to understand why it
isn't a no-brainer to change. Why is there a fight over a trivial change
which will ensure that PostgreSQL aligns to the documented behavior of
open()
(Why characterise this as a fight, rather than
In article [EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] writes:
One possible approach is to do the invalidation on a sufficiently coarse
grain that we don't care. For example, I would be inclined to make any
change in a table's schema invalidate all plans that use that table at
all; that
Harald Fuchs wrote:
In article [EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] writes:
One possible approach is to do the invalidation on a sufficiently coarse
grain that we don't care. For example, I would be inclined to make any
change in a table's schema invalidate all plans that use
Bruce Momjian wrote:
One idea would be to record if the function uses non-temp tables, temp
tables, or both, and invalidate based on the type of table being
invalidated, rather than the table name itself. I can imagine this
hurting temp table caching, but at least functions using regular tables
Harald Fuchs [EMAIL PROTECTED] writes
How about using an even coarser grain? Whenever something in the
database in question changes, blindly throw away all cached plans for
this DB.
If we clearly define what is something in database in question, we have to
trace all the objects the query
This may be totally irrelevant:
Our current load distributors, like pgpool, have no way of knowing the
side effects of backend functions. It would be interesting if the
client could send each potential query to the master saying, execute
this query if there are side effects, otherwise do no
On Mon, 2005-03-14 at 20:06 -0500, Bruce Momjian wrote:
Harald Fuchs wrote:
In article [EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] writes:
One possible approach is to do the invalidation on a sufficiently coarse
grain that we don't care. For example, I would be inclined to make
Qingqing Zhou wrote:
Second (as Tom says), some changes can hardly be traced. For example, we
only use function A. But function A cites function B, function B cites
function C. when C changes, how do we know that we should worry about our
plan?
I don't see that this is a major problem. If a plan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
http://developer.postgresql.org/docs/postgres/catalog-pg-trigger.html
says currently unused and a desultory search through the sources
confirms that. I imagine it was put there with the intent of adding
column info later on.
[EMAIL PROTECTED] wrote:
The point is that this *is* silly, but I am at a loss to understand why
it
isn't a no-brainer to change. Why is there a fight over a trivial change
which will ensure that PostgreSQL aligns to the documented behavior of
open()
(Why characterise this as a fight,
I really don't intend to do that, and it does seem to happen a lot. I am
the first to admit I lack tact, but often times I view the decisions made
as rather arbitrary and lacking a larger perspective, but that is a rant I
don't want to get right now.
Perhaps it's your lack of a real name and
At 2005-03-14 16:25:22 -0500, [EMAIL PROTECTED] wrote:
The file descriptor returned by open is the lowest numbered unused
descriptor. [...]
What is meant by unused?
Perhaps you should actually look at the standard.
The open( ) function shall return a file descriptor for the named
Christopher Kings-Lynne wrote:
I really don't intend to do that, and it does seem to happen a lot. I am
the first to admit I lack tact, but often times I view the decisions made
as rather arbitrary and lacking a larger perspective, but that is a rant I
don't want to get right now.
Christopher Kings-Lynne wrote:
I really don't intend to do that, and it does seem to happen a lot. I
am
the first to admit I lack tact, but often times I view the decisions
made
as rather arbitrary and lacking a larger perspective, but that is a
rant I
don't want to get right now.
Perhaps it's your lack of a real name and complete anonyminity (hence
invulnerablility) that gets to people...
Is it fixed?
Yeah, hi Mark :)
Chris
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Mark Woodward wrote:
Christopher Kings-Lynne wrote:
I really don't intend to do that, and it does seem to happen a lot. I
am
the first to admit I lack tact, but often times I view the decisions
made
as rather arbitrary and lacking a larger perspective, but that is a
rant I
On Mon, Mar 14, 2005 at 10:45:51PM -0500, Bruce Momjian wrote:
Mark Woodward wrote:
Bruce, I did want to meet you to a greater extent, but you we surrounded
by people and looked quite busy.
Yea, I was just teasing. It was a very busy conference. I remember at
night just wanting to turn
Peter Eisentraut wrote:
o Disallow encodings like UTF8 which PostgreSQL supports
but the operating system does not (already disallowed by
pginstaller)
I think the warning that initdb shouts out is already enough for this.
I don't think we want to disallow
Alvaro Herrera wrote:
On Mon, Mar 14, 2005 at 10:45:51PM -0500, Bruce Momjian wrote:
Mark Woodward wrote:
Bruce, I did want to meet you to a greater extent, but you we surrounded
by people and looked quite busy.
Yea, I was just teasing. It was a very busy conference. I remember
Neil Conway wrote:
- it is the responsibility of the call site managing the prepared plan
to check whether a previously prepared plan is invalid or not -- and to
take the necessary steps to replan it when needed.
Does this mean that clients that use PREPARE/Parse need to handle plan
invalidated
Oliver Jowett wrote:
Does this mean that clients that use PREPARE/Parse need to handle plan
invalidated as a possible response to EXECUTE/Bind, or will the backend
keep the query string / parse tree around and replan on next execution?
The latter -- the client won't be aware that replanning took
Neil Conway [EMAIL PROTECTED] writes
I don't see that this is a major problem. If a plan A invokes a function
B, then changes to B will need to invalidate A; that should be pretty
easy to arrange. If B is a PL/PgSQL function that invokes a function C,
it will probably cache a plan involving
Added to TODO list:
* Allow sequential scans to take advantage of other concurrent
sequentiqal scans, also called Synchronised Scanning
---
Jeff Davis wrote:
I had an idea that might improve parallel seqscans on the
Tom Lane wrote:
I hadn't really gotten as far as working out a reasonable API for the
module. The $64 question seems to be what is the input: a textual query
string, a raw parse analysis tree, or what?
It should be easy enough to accept either, and then convert from the
query string into a raw
Neil Conway [EMAIL PROTECTED] writes:
(BTW, another thing to consider is how the rewriter will effect a plan's
dependencies: I think we should probably invalidate a plan when a
modification is made to a view or rule that affected the plan.
This issue goes away as long as you follow the rule
Neil Conway [EMAIL PROTECTED] writes:
Oliver Jowett wrote:
Does this mean that clients that use PREPARE/Parse need to handle plan
invalidated as a possible response to EXECUTE/Bind, or will the backend
keep the query string / parse tree around and replan on next execution?
The latter --
Qingqing Zhou wrote:
I don't quite understand the difference between a SQL function and a
PL/PgSQL function here - since there is a overlapped functionality that we
could implement by SQL function or by PL/PgSQL function.
The difference is between an inlined function (which is integrated
directly
Qingqing Zhou [EMAIL PROTECTED] writes:
This is the key point (say this is point_1) - we must make sure how deep we
have to go to check validity.
The recorded plan has to somehow mention all the inlined functions that
were expanded out of existence. There might be several levels of such
Will PQexecParams automatically escape bytea data as it goes in, or must
one run it through PQescapeBytea first?
Chris
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's
I'm currently adding support for the v3 protocol in PHP pgsql extension.
I'm wondering if anyone minds if I lift documentation wholesale from
the PostgreSQL docs for the PHP docs for these functions. For instance,
the fieldcodes allowed for PQresultErrorField, docs on
PQtransactionStatus,
58 matches
Mail list logo
