Guy Fraser <[EMAIL PROTECTED]> writes:
> I have tried reformatting dates in many ways but every thing I have
> tried fails.
As a rule, COPY will interpret incoming dates according to the current
setting of the DATESTYLE variable. It'd help if you explained the date
format you are trying to read
On Fri, 27 Oct 2000, Tom Lane wrote:
> BTW, does it strike anyone else as peculiar that the host(),
> broadcast(), network(), and netmask() functions yield results
> of type text, rather than type inet? Seems like it'd be considerably
> more useful if they returned values of type inet with mask
On Fri, 27 Oct 2000, Tom Lane wrote:
> A more interesting question is whether the system needs to provide any
> assisting functions that aren't there now. The lookup function you guys
> are postulating seems like it would be (in the simple cases)
> create function my_network(inet) returns
* Tom Lane <[EMAIL PROTECTED]> [001027 20:45]:
> Sigh ... I was really hoping not to get drawn into fixing these issues
> for 7.1, but ...
[SNIP]
Works WELL for me. THANK YOU, Tom.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: [E
"Kevin O'Gorman" <[EMAIL PROTECTED]> writes:
> 2) It does NOT preserve the odd syntax I found when I started looking
> at this, where a SELECT statement could begin with parentheses. Thus,
> (SELECT a from foo) order by a;
> fails.
Um, as a general rule that's not an acceptable limitation. Co
"Kevin O'Gorman" <[EMAIL PROTECTED]> writes:
> All that being said, I'm not sure enough notice has been taken of one
> aspect of the changes already in place, and likely to become more
> pronounced. It may be okay with everybody, but I don't want it to be
> a big surprise: queries may no longer
"Kevin O'Gorman" <[EMAIL PROTECTED]> writes:
> This just occurred to me: how would you sort the results of this query?
> The path of least resistance from the way things work now would be most
> non-obvious: put the ORDER BY on the leftmost query. It looks like this
> (SELECT * INTO newtable FROM
> (SELECT * INTO newtable FROM table1) UNION (SELECT * FROM table2);
Possibly a silly (and definitely not standards-conformant) suggestion:
Maybe grammar should be amended to allow for
(SELECT * FROM table1) UNION (SELECT * FROM table2) INTO newtable
i.e.
union_expr:
(select_expr) union (unio
e) have a function network(inet) which would look up the address in a
table of networks using longest-prefix-match. I.E. something similar to:
>> No need. Let the user do it themselves. Similar to what we did for
>> macaddr's back in the summer.
> Yeah, it can be user-defined (or a c
On Fri, 27 Oct 2000, Guy Fraser wrote:
> Hi
>
> I have tried reformatting dates in many ways but every thing I have
> tried fails.
I've been able to use copy to import date values in a simple test:
create table dt (a date);
copy dt from stdin;
01-12-2000
12-11-1999
\.
put the date values in fi
one more small request:
int8_inet(inet) and inet_int8(int8): functions to convert an inet to an
int8 and back. (not an int4, since postgres int4s are signed)
This allows me to do some additional manipulations on values. (ie. given a
host, determine its default gateway, for us, it is always first
Hi Zoltan. Your recent mail has had a reply-to of
Kovacs Zoltan Sandor <[EMAIL PROTECTED]>
and a couple of messages from me to you have bounced. It looks like it
reaches the machine, but says that the "user is unknown". Is that really
a good address for you? Hope to hear from you...
* Tom Lane <[EMAIL PROTECTED]> [001027 17:54]:
> Alex Pilosov <[EMAIL PROTECTED]> writes:
> > On Fri, 27 Oct 2000, Tom Lane wrote:
> >> BTW, does it strike anyone else as peculiar that the host(),
> >> broadcast(), network(), and netmask() functions yield results
> >> of type text, rather than typ
Picking up from a discussion several months back, the build now uses the
-rpath option (or -Wl,-R or whatever yours uses) to store the location of
the shared libraries into the executables and the shared libraries
themselves. That means that the LD_LIBRARY_PATH/ld.so.conf thing should
no longer b
* Alex Pilosov <[EMAIL PROTECTED]> [001027 21:20]:
> Please read below if the whole thing with inet/cidr doesn't make you puke
> yet ;) The semi-longish proposal is at the bottom.
>
> On Fri, 27 Oct 2000, Tom Lane wrote:
[snip]
> Actually, now that I think longer about the whole scheme in terms o
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Fine, but host() rejects CIDR types right now
What's your point? network() doesn't behave the way you want right now,
either.
regards, tom lane
On Fri, 27 Oct 2000, Tom Lane wrote:
> BTW, does it strike anyone else as peculiar that the host(),
> broadcast(), network(), and netmask() functions yield results
> of type text, rather than type inet? Seems like it'd be considerably
> more useful if they returned values of type inet with maskl
I wrote:
> There is no subset type that corresponds to "valid host addresses
> only" --- if there were, it would be a subset of INET but would have
> no valid values in common with CIDR.
I take that back --- CIDR accepts w.x.y.z/32 for any w.x.y.z, which
would include valid host addresses. (But
Sigh ... I was really hoping not to get drawn into fixing these issues
for 7.1, but ...
It seems like much of the problem is that there isn't any easy way to
choose between CIDR-style display format ('127.1/16') and INET-style
format ('127.1.0.0/16'). We need to bite the bullet and add conversio
(This is mostly directed at Vadim, but kibitzing is welcome.)
Here's what I plan to do to make DROP TABLE rollbackable and clean up
the handling of CREATE TABLE rollback. Comments?
Overview:
1. smgrcreate() will create the file for the relation same as it does now,
and will add the rel's RelF
Please read below if the whole thing with inet/cidr doesn't make you puke
yet ;) The semi-longish proposal is at the bottom.
On Fri, 27 Oct 2000, Tom Lane wrote:
> Alex Pilosov <[EMAIL PROTECTED]> writes:
> > We should have as much error-checking as possible.
>
> How so? Without a netmask you
On Fri, 27 Oct 2000, Larry Rosenman wrote:
> Not necessarily, especially for novices. Some people may want to
> store the netmask with the IP of a host (think ifconfig being
> AUTOGEN'd).
For a single host? Or for a network of hosts? But yes, I see your point if
a single host has x interfaces,
Alex Pilosov <[EMAIL PROTECTED]> writes:
> We should have as much error-checking as possible.
Only possible with a much tighter definition of what the intended use
of each type is. For example, you seem to be saying that broadcast
addresses aren't valid inet values, with which I do not agree unl
* Alex Pilosov <[EMAIL PROTECTED]> [001027 21:36]:
> On Fri, 27 Oct 2000, Larry Rosenman wrote:
>
> > Not necessarily, especially for novices. Some people may want to
> > store the netmask with the IP of a host (think ifconfig being
> > AUTOGEN'd).
> For a single host? Or for a network of hosts
Alex Pilosov <[EMAIL PROTECTED]> writes:
> On Fri, 27 Oct 2000, Tom Lane wrote:
>> BTW, does it strike anyone else as peculiar that the host(),
>> broadcast(), network(), and netmask() functions yield results
>> of type text, rather than type inet?
> I absolutely agree, except for network(), whic
Bruce Momjian wrote:
>
> > However, the upgrade gotcha has left a very bitter taste in more than
> > one user's mouth. I'll not say more about that now, as I've said quite
> > enough in the past. And I'm still trying to figure out enough of the
> > internals of the storage manager to try to wri
> Ok, here goes:
Cool, a list.
> * Location-agnostic installation. Documentation (which I'll be happy to
> contribute) on that. Peter E is already working in this area. Getting
> the installation that 'make install' spits out massaged into an FHS
> compliant setup is the majority of the RP
* Tom Lane <[EMAIL PROTECTED]> [001027 21:53]:
> e) have a function network(inet) which would look up the address in a
> table of networks using longest-prefix-match. I.E. something similar to:
>
> >> No need. Let the user do it themselves. Similar to what we did for
> >> macaddr's bac
Tom Lane writes:
> But it's still dependent on the user's PATH to point to the right
> executables, no?
This is what's puzzling me. There's code in there that tries to locate
initdb and uses the executables and bki files (7.0 only) from the same
tree. Evidently this code does not always work r
On Fri, 27 Oct 2000, Tom Lane wrote:
> Alex Pilosov <[EMAIL PROTECTED]> writes:
> > Also, I agree with Larry that cidr _must_ be printed with 4 octets in
> > them, whether they are 0 or not. (i.e. it should print 207.158.72.0/24)
>
> > This is the standard way of specifying addresses in all netw
> However, the upgrade gotcha has left a very bitter taste in more than
> one user's mouth. I'll not say more about that now, as I've said quite
> enough in the past. And I'm still trying to figure out enough of the
> internals of the storage manager to try to write the migration tools
> myself.
Larry Rosenman <[EMAIL PROTECTED]> writes:
> I.E. for select network('207.158.72.0/24')
> I get
> 207.158.72.0
To my mind that should be done with host(), not network(). If you strip
the masklen information then what you have is no longer a network
specification, so expecting a function named n
I'm back a bit from the tip of the CVS tree, so this might not
be current, but as of around 8 October, installing as root gets
in the way of later operations. I think this is an artifact
of having Perl in the build.
I did a 'su root' and a 'make install', then as my normal user
self, attempted t
* Tom Lane <[EMAIL PROTECTED]> [001027 17:41]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > Fine, but host() rejects CIDR types right now
>
> What's your point? network() doesn't behave the way you want right now,
> either.
Fine, network() can return CIDR (207.158.72/24), but allow host(
Larry Rosenman writes:
> Sounds like an easy one for a newbie to pick up. Let me look at it,
> but I think I'd like dibs on it.
Actually, initdb of 7.1 gets the directory location of the bootstrap files
wired in at build time. The only way to override it is to use the -L
option. So the probl
On Fri, 27 Oct 2000, Tom Lane wrote:
> The way I'm visualizing this, INET is a generalized type that will store
> any 4-octet address plus any netmask width from 1 to 32. This includes
> not only host addresses, but network specs and broadcast addresses.
> CIDR is a subset type that only accepts
Okay, here's my attempt at fixing the problems with parentheses in
subqueries. It passes the normal 'runcheck' tests, and I've tried
a few simple things like
select 1 as foo union (select 2) order by foo;
There are a few things that it doesn't do that have been talked
about here at l
Kevin O'Gorman wrote:
>
> [EMAIL PROTECTED] wrote:
> >
> > "Kevin O'Gorman" <[EMAIL PROTECTED]> writes:
> > Anyway, the bottom line of all this rambling is that if you can get
> > rid of the distinction between SelectStmt and select_clause altogether,
> > that would be fine with me. You might co
* Tom Lane <[EMAIL PROTECTED]> [001027 17:04]:
> BTW, does it strike anyone else as peculiar that the host(),
> broadcast(), network(), and netmask() functions yield results
> of type text, rather than type inet? Seems like it'd be considerably
> more useful if they returned values of type inet w
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> But it's still dependent on the user's PATH to point to the right
>> executables, no?
> This is what's puzzling me. There's code in there that tries to locate
> initdb and uses the executables and bki files (7.0 only) from the same
> tree.
Yeah, b
[EMAIL PROTECTED] wrote:
>
> "Kevin O'Gorman" <[EMAIL PROTECTED]> writes:
> Anyway, the bottom line of all this rambling is that if you can get
> rid of the distinction between SelectStmt and select_clause altogether,
> that would be fine with me. You might consider looking at whether you
> can
At 12:18 27/10/00 -0400, Tom Lane wrote:
>
>1. If DECLARE CURSOR does not contain a LIMIT, continue to plan on the
>basis of 10%-or-so fetch (I'd consider anywhere from 5% to 25% to be
>just as reasonable, if people want to argue about the exact number;
>perhaps a SET variable is in order?). 10%
* Tom Lane <[EMAIL PROTECTED]> [001027 17:29]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > I.E. for select network('207.158.72.0/24')
> > I get
> > 207.158.72.0
>
> To my mind that should be done with host(), not network(). If you strip
> the masklen information then what you have is no lo
Philip Warner <[EMAIL PROTECTED]> writes:
> At 12:18 27/10/00 -0400, Tom Lane wrote:
>> 1. If DECLARE CURSOR does not contain a LIMIT, continue to plan on the
>> basis of 10%-or-so fetch (I'd consider anywhere from 5% to 25% to be
>> just as reasonable, if people want to argue about the exact numb
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Bonus project: find out why initdb is picking up the wrong files in the
> > first place.
>
> User error is a sufficient explanation in the cases I've seen: wrong
> postgres executable found first in PATH, PGLIB or -L pointing to wrong
> place, e
BTW, does it strike anyone else as peculiar that the host(),
broadcast(), network(), and netmask() functions yield results
of type text, rather than type inet? Seems like it'd be considerably
more useful if they returned values of type inet with masklen = 32
(except for network(), which would kee
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Actually, initdb of 7.1 gets the directory location of the bootstrap files
> wired in at build time. The only way to override it is to use the -L
> option. So the problem seems a lot less grave that way.
That does seem to reduce the odds of wrong-b
On Fri, 27 Oct 2000, Tom Lane wrote:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > OK, what I really meant was a way to coerce a CIDR entity to INET so
> > that host() can work with a CIDR type to print all 4 octets.
>
> Hm. I don't see any really good reason why host() rejects CIDR input
Hi
I have tried reformatting dates in many ways but every thing I have
tried fails.
I used insert and update to create and change dates with different
styles and
was successful.
Is this a known bug?
Is their a fix for this bug?
or
Do I have to import date variables using insert/update statem
Trond Eivind Glomsrød wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be
> > fulfilled by libpq.so.2.1 (how _can_ it know? A client linked to 2.0
> > might fail if 2.1 were to be loaded under it (hypothetically)).
> There usually
I can't type today
- Forwarded message from Larry Rosenman <[EMAIL PROTECTED]> -
From: Larry Rosenman <[EMAIL PROTECTED]>
Subject: Re: [HACKERS] Summary: what to do about INET/CIDR
Date: Fri, 27 Oct 2000 15:09:36 -0500
Message-ID: <[EMAIL PROTECTED]>
User-Agent: Mutt/1.3.10i
X-Mailer:
* Tom Lane <[EMAIL PROTECTED]> [001027 15:14]:
> Alex Pilosov <[EMAIL PROTECTED]> writes:
> > Also, I agree with Larry that cidr _must_ be printed with 4 octets in
> > them, whether they are 0 or not. (i.e. it should print 207.158.72.0/24)
>
> > This is the standard way of specifying addresses in
Alex Pilosov <[EMAIL PROTECTED]> writes:
> Also, I agree with Larry that cidr _must_ be printed with 4 octets in
> them, whether they are 0 or not. (i.e. it should print 207.158.72.0/24)
> This is the standard way of specifying addresses in all network equipment.
> RFC specifies that, just the li
[BCC to Hackers -- cc: to PORTS, as, as Bruce correctly pointed out,
that's where this discussion belongs.]
Trond Eivind Glomsrød wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > My gut feel is that RedHat may be better off shipping 7.0.x if the
> > library version numbers are a contributory p
Larry Rosenman <[EMAIL PROTECTED]> writes:
> OK, what I really meant was a way to coerce a CIDR entity to INET so
> that host() can work with a CIDR type to print all 4 octets.
Hm. I don't see any really good reason why host() rejects CIDR input
in the first place. What's wrong with producing
On Fri, 27 Oct 2000, Larry Rosenman wrote:
> and network(cidr) should print ONLY the octets, not the mask...
Agreed. There's a function to get the mask size, and the network should
just return the network. Otherwise, it is impossible to use.
-alex
Bruce Momjian wrote:
> > I appreciate the fact that we are not here to make it easy for
> > distributors to package our software. I also appreciate the fact that
> > if you don't at least make an effort to work with major distributors
> > (and RedHat, TurboLinux, Caldera, and SuSE together comp
> > 1. Add a --version switch to postgres or postmaster to print its version
> > and exit.
postmaster already has this. Someone can copy the code into
tcop/postgres.c as well. But should we not use the catversion for this?
> > to a compatible library directory. Alternatively, add version info
Tom Lane writes:
> 1. A data value like '10.1.2.3/16' is a legal INET value (it implies
> the host 10.1.2.3 in the network 10.1/16) but not a legal CIDR value.
> Hence, cidr_in should reject such a value. Up to now it hasn't.
Nod.
> 2. We do not have a datatype corresponding strictly to a ho
Lamar Owen <[EMAIL PROTECTED]> writes:
> My gut feel is that RedHat may be better off shipping 7.0.x if the
> library version numbers are a contributory problem.
We could provide compat-packages with just neeeded libraries.
> The data upgrade problem is a bigger problem. To which RedHat migh
Lamar Owen <[EMAIL PROTECTED]> writes:
> Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be
> fulfilled by libpq.so.2.1 (how _can_ it know? A client linked to 2.0
> might fail if 2.1 were to be loaded under it (hypothetically)).
>
> Now, that doesn't directly effect the PostgreSQL
* Alex Pilosov <[EMAIL PROTECTED]> [001027 14:43]:
> On Fri, 27 Oct 2000, Larry Rosenman wrote:
> > ler=# select * from ler_test;
> > net | host
> > ---+--
> > 207.158.72/24 | 207.158.72.11/24
> > (1 row)
> >
> > ler=# select host(net::inet) from ler_
[ Charset ISO-8859-1 unsupported, converting... ]
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > Let them. It is their decision. Frankly, I have seen this attitude
> > before, and I don't like it. Just the mention that "Gee, if you don't
> > cooperate, we may yank you," is really a veiled t
On Fri, 27 Oct 2000, Larry Rosenman wrote:
> ler=# select * from ler_test;
> net | host
> ---+--
> 207.158.72/24 | 207.158.72.11/24
> (1 row)
>
> ler=# select host(net::inet) from ler_test;
> ERROR: CIDR type has no host part
> ERROR: CIDR type has
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Let them. It is their decision. Frankly, I have seen this attitude
> before, and I don't like it. Just the mention that "Gee, if you don't
> cooperate, we may yank you," is really a veiled threat. Now, I know you
> aren't saying that, but the "if yo
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bonus project: find out why initdb is picking up the wrong files in the
> first place.
User error is a sufficient explanation in the cases I've seen: wrong
postgres executable found first in PATH, PGLIB or -L pointing to wrong
place, etc.
The chang
Tom Lane wrote:
>
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be
> > fulfilled by libpq.so.2.1 (how _can_ it know? A client linked to 2.0
> > might fail if 2.1 were to be loaded under it (hypothetically)).
>
> If so, I claim RPM is
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Inet is supposed to be host address, with optional network specification.
Agreed. As such, it probably should always display all 4 octets
regardless of the maskwidth. It doesn't do that at the moment:
regression=# select '127.0.0.1/8'::inet;
?col
> > To answer your question, there are no pending changes in libpq that
> > would mandate a major version bump (ie, nothing binary-incompatible,
> > AFAIK). We could ship it with the exact same version number, but then
> > how are people to tell whether they have a 7.0 or 7.1 libpq?
>
> If there
Hiroshi and I had a discussion last night that needs to reach a wider
audience than just the bystanders on pgsql-committers. Let me see if
I can reconstruct the main points.
In 7.0, a LIMIT clause can appear in a DECLARE CURSOR, but it's ignored:
play=> select * from vv1;
f1
-
As a large part of you will have noticed by now, this past week has been
killer on the mailing lists. One of the web clients on that machine
decided to not warn us of one of their countries holidays, and, as a
result, we got hit with a diluge of hits, similar to a slashdot effect ...
We ordered
Tom Lane <[EMAIL PROTECTED]> writes:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be
> > fulfilled by libpq.so.2.1 (how _can_ it know? A client linked to 2.0
> > might fail if 2.1 were to be loaded under it (hypothetically)).
You lin
* Tom Lane <[EMAIL PROTECTED]> [001027 09:49]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > Also a way to get network (.0) and broadcast (all ones) for a cidr
> > block out of our stuff.
>
> network() and broadcast() have been there all along ...
OK, what I really meant was a way to coerce a
> > What would be good is for someone to constructively make a posting about
> > the known problems, and come up with acceptable solutions. Asking us to
> > fix it really isn't going to help because we don't deal with RPM's here,
> > and we don't have enough free time to make significant changes
* Larry Rosenman <[EMAIL PROTECTED]> [001027 11:08]:
> * Tom Lane <[EMAIL PROTECTED]> [001027 09:49]:
> > Larry Rosenman <[EMAIL PROTECTED]> writes:
> > > Also a way to get network (.0) and broadcast (all ones) for a cidr
> > > block out of our stuff.
> >
> > network() and broadcast() have been
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be
> > fulfilled by libpq.so.2.1 (how _can_ it know? A client linked to 2.0
> > might fail if 2.1 were to be loaded under it (hypothetically)).
>
> If so, I claim RPM is broken.
>
> The wh
On Fri, Oct 27, 2000 at 09:21:23PM +1000, Philip Warner wrote:
>
> [To hackers this time]
>
> At 20:59 26/10/00 -0400, Tom Lane wrote:
> >Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> >> Yes I want to give optimizer a hint "return first rows fast".
> >> When Jan implemented LIMIT first,there was
"Kevin O'Gorman" <[EMAIL PROTECTED]> writes:
> I've been poking into the syntax in gram.y, and finding
> that the provision of parentheses for SELECT statements
> is pretty broken. I have previously posted examples of
> odd things. On closer examination, it appears to need
> an overhaul.
> Ther
Bruce Momjian wrote:
> Lamar Owen wrote:
> > May I ask: is it necessary? Have there been version-bumping changes to
> > libpq since 7.0.x? (With the rate that necessary improvement is
> > happening to PostgreSQL, probably).
> No, only major releases have bumps.
> See pgsql/src/tools/RELEASE_C
* Larry Rosenman <[EMAIL PROTECTED]> [001027 09:51]:
> * Tom Lane <[EMAIL PROTECTED]> [001027 09:49]:
> > Larry Rosenman <[EMAIL PROTECTED]> writes:
> > > Also a way to get network (.0) and broadcast (all ones) for a cidr
> > > block out of our stuff.
> >
> > network() and broadcast() have been
* Tom Lane <[EMAIL PROTECTED]> [001027 09:49]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > Also a way to get network (.0) and broadcast (all ones) for a cidr
> > block out of our stuff.
>
> network() and broadcast() have been there all along ...
but don't work on CIDR types.
LER
>
>
Lamar Owen <[EMAIL PROTECTED]> writes:
> Unfortunately RPM deems a dependency upon libpq.so.2.0 to not be
> fulfilled by libpq.so.2.1 (how _can_ it know? A client linked to 2.0
> might fail if 2.1 were to be loaded under it (hypothetically)).
If so, I claim RPM is broken.
The whole point of maj
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Also a way to get network (.0) and broadcast (all ones) for a cidr
> block out of our stuff.
network() and broadcast() have been there all along ...
regards, tom lane
Todays Sources still die:
cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O
-K inline -o copy.o copy.c
cc -c -I/usr/local/include -I../../../src/include -I../../../src/interfaces/libpq -O
-K inline -o startup.o startup.c
cc -c -I/usr/local/include -I../../../s
[To hackers this time]
At 20:59 26/10/00 -0400, Tom Lane wrote:
>Hiroshi Inoue <[EMAIL PROTECTED]> writes:
>> Yes I want to give optimizer a hint "return first rows fast".
>> When Jan implemented LIMIT first,there was an option
>> "LIMIT ALL" and it was exactly designed for the purpose.
>
>Well
[To hackers this time]
At 12:11 27/10/00 +0900, Hiroshi Inoue wrote:
>
>For example,LIMIT ALL means LIMIT 1 for optimizer and means
>no LIMIT for executor.
>Comments ?
>
It seems there's two possibilities:
(a) You know you will only use a limited number of rows, but you are not
sure exactly how
Just tested this on latest devel. version, and there does seem to be a
problem.
[]$ psql test
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate
I've been poking into the syntax in gram.y, and finding
that the provision of parentheses for SELECT statements
is pretty broken. I have previously posted examples of
odd things. On closer examination, it appears to need
an overhaul.
There are two problems with this: (1) I'm new here, I don't
k
Date: Thu, 26 Oct 2000 20:49:22 -0400
From: Tom Lane <[EMAIL PROTECTED]>
Right. Also, I believe it's possible that such a grammar will behave
differently depending on which yacc you process it with, which would be
bad. (We have not yet taken the step of insisting that pgsql's gra
[Taken off GENERAL, added HACKERS to cc:]
Bruce Momjian wrote:
> > He's meaning the libpq version for dynamic link loading. Is the
> > libpq.so lib changing versions (like the change from 6.5.x to 7.0.x
> > changed from libpq.so.2.0 to libpq.so.2.1, which broke binary RPM
> > compatibility for o
There is an _excellent_ PostgreSQL article in the current (November
2000) issue of Linux Journal. It is fair, even-handed, and was even
written by a MySQL user. Almost a convert, I might add. (He even liked
the RPM's :-))
It's not linked on their online site (www.linuxjournal.com) as of yet.
O
* Tom Lane <[EMAIL PROTECTED]> [001026 18:46]:
> After reviewing a number of past threads about the INET/CIDR mess,
> I have concluded that we should adopt the following behavior:
>
> 1. A data value like '10.1.2.3/16' is a legal INET value (it implies
> the host 10.1.2.3 in the network 10.1/16)
[ Blind CC to general added for comment below.]
> [Taken off GENERAL, added HACKERS to cc:]
>
> Bruce Momjian wrote:
> > > He's meaning the libpq version for dynamic link loading. Is the
> > > libpq.so lib changing versions (like the change from 6.5.x to 7.0.x
> > > changed from libpq.so.2.0 t
makes sense to me
On Thu, 26 Oct 2000, Tom Lane wrote:
> After reviewing a number of past threads about the INET/CIDR mess,
> I have concluded that we should adopt the following behavior:
>
> 1. A data value like '10.1.2.3/16' is a legal INET value (it implies
> the host 10.1.2.3 in the netwo
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > Saw Tom's commits, now it breaks here:
> > cc -c -I/usr/local/include -I../../../src/include -DFRONTEND -I.
>-DSYSCONFDIR='"/home/ler/pg-test/etc/postgresql"' -O -K inline -K PIC -o fe-connect.o
>fe-connect.c
> > UX:acomp: ERROR: "../../../src/inc
95 matches
Mail list logo
