Emmanuel Charpentier wrote:
> Tom Lane wrote:
> > Daniel Kalchev <[EMAIL PROTECTED]> writes:
> >
> >>If ever this happens, same should be considered for tables created via the
> >>SELECT INTO statement. These are in many cases 'temporary' in nature and do
> >>not need OIDs (while making much use
Tom Lane wrote:
Daniel Kalchev <[EMAIL PROTECTED]> writes:
If ever this happens, same should be considered for tables created via the
SELECT INTO statement. These are in many cases 'temporary' in nature and do
not need OIDs (while making much use of the OIDs counter).
SELECT INTO does create
Daniel Kalchev <[EMAIL PROTECTED]> writes:
> If ever this happens, same should be considered for tables created via the
> SELECT INTO statement. These are in many cases 'temporary' in nature and do
> not need OIDs (while making much use of the OIDs counter).
SELECT INTO does create tables withou
If ever this happens, same should be considered for tables created via the
SELECT INTO statement. These are in many cases 'temporary' in nature and do
not need OIDs (while making much use of the OIDs counter).
Daniel
---(end of broadcast)---
TIP
>>>Neil Conway said:
> On Fri, 2003-01-10 at 21:27, Christopher Kings-Lynne wrote:
> > So what actually is the point of OIDs then?
>
> My understanding is that they're used to uniquely identify entries in
> system catalogs. If there's a good reason to make use of OIDs on user
> tables, I can
Neil Conway writes:
> > On the other hand, if we do do that then (a) pg_dump output
> > becomes even less portable than it is now, and (b) upgraded databases
> > will still have OIDs, which renders the "improved storage efficiency"
> > argument a bit thin.
> Personally, I don't think (a) is that
On Fri, 2003-01-10 at 22:14, Ashley Cambrell wrote:
> First problem though is that you have to know the sequence name that
> is autogenerated from the serial
... which is not a legitimate problem, IMHO.
> secondly, I thought that sequences worked outside of transactions
They do, but obviously no
On Fri, 2003-01-10 at 21:27, Christopher Kings-Lynne wrote:
> So what actually is the point of OIDs then?
My understanding is that they're used to uniquely identify entries in
system catalogs. If there's a good reason to make use of OIDs on user
tables, I can't see it...
Cheers,
Neil
--
Neil Co
Neil Conway wrote:
On Fri, 2003-01-10 at 18:17, Ashley Cambrell wrote:
The problem with getting rid of OIDs as default is there is then no way
to get the primary key of a just inserted row with out OIDs (as far as I
know)
Use currval() on the PK sequence -- if you call i
So what actually is the point of OIDs then? If you set OIDs ff by default
and use currval, what's the point of having OIDs at all?
Chris
On 10 Jan 2003, Neil Conway wrote:
> On Fri, 2003-01-10 at 18:17, Ashley Cambrell wrote:
> > The problem with getting rid of OIDs as default is there is then
The real question is how tables are dumped from 7.3 and below. Does it
always explicitly specify 'WITH OIDS' for tables with OIDs?
If not, this would have little benefit for me I guess...
I still vote for the ability to drop OIDs from a table :)
Chris
On 10 Jan 2003, Neil Conway wrote:
> Folk
On Fri, 2003-01-10 at 18:44, Tom Lane wrote:
> Are you intending that pg_dump will always attach either WITH OIDS or
> WITHOUT OIDS to its CREATE TABLE commands?
Now that I think about it, I'd think pg_dump should attach one or the
other to all CREATE TABLE commands, regardless of the GUC variable
Neil Conway <[EMAIL PROTECTED]> writes:
> Is it a good idea for CREATE TABLE to default to WITHOUT OIDS, rather
> than WITH OIDS?
Are you intending that pg_dump will always attach either WITH OIDS or
WITHOUT OIDS to its CREATE TABLE commands?
If we do not do so, the behavior of a dump and reload
On Fri, 2003-01-10 at 18:17, Ashley Cambrell wrote:
> The problem with getting rid of OIDs as default is there is then no way
> to get the primary key of a just inserted row with out OIDs (as far as I
> know)
Use currval() on the PK sequence -- if you call it from within the query
that inserted a
Neil Conway wrote:
>Folks,
>
>Is it a good idea for CREATE TABLE to default to WITHOUT OIDS, rather
>than WITH OIDS? Naturally, this would (a) be some time in the future
>(7.5, perhaps) and (b) only apply to user tables.
>
>
>The main disadvantage I can see is just backward compatibility. In order
Folks,
Is it a good idea for CREATE TABLE to default to WITHOUT OIDS, rather
than WITH OIDS? Naturally, this would (a) be some time in the future
(7.5, perhaps) and (b) only apply to user tables.
The two advantages I can see are:
(1) Makes the storage of most tables more efficient; while you *ca
16 matches
Mail list logo
